Re: bfd_arch_info.fill vs ARM (bug 13616)

[Matthew Gretton-Dann <matthew dot gretton-dann at arm dot com>]

On Tue, Jan 31, 2012 at 09:03:20PM +0000, Roland McGrath wrote:
> I took a crack at adding the ARM support for fixing bug 13616.  But I think
> the new hook's signature passes insufficient information for all cases.
> It's easy to get right for 32-bit ARM.  But the hook has no way to know
> whether the preceding code was ARM or Thumb.
> 
> I'm not even really sure how you're supposed to determine that.  Best I can
> figure is you're supposed to look at the symbol table for symbols named
> "$a" or "$t" in that section, the highest-addressed of those indicating
> which mode was being assembled at the end of the section.
> 
> Whatever the details, it seems certain it will require that the hook get at
> least the asection pointer.

As you say this is indeed horrible, so can I take a step back and ask why we
want to insert no-ops as padding?

A quick read of the ELF standard is that the padding in this case is
undefined.  Only 'unrecognized sections' must be padded with a known value -
zero.  The padding between sections of known types may have values different
from zero, where appropriate.

An alternative view would be that it seems strange that someone branching
into some padding (for whatever reason) gets to fall through into some
'real' code.  A more useful padding instruction would be one which took an
illegal/undefined instruction trap of some sort, so the user became aware
that a program was behaving oddly.

Apologies if there is something obvious I have missed - I am just trying to
understand why this is a desired change - or if there is another way to
achieve the same result.

Thanks,

Matt

-- 
Matthew Gretton-Dann
Principal Engineer, PD Software, ARM Ltd.