Re: bfd_arch_info.fill vs ARM (bug 13616)

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

On Wed, Feb 01, 2012 at 05:27:15PM +0000, Roland McGrath wrote:
> Perhaps you missed my original posting about this, when I was first trying
> to address it in the assembler (which is not sufficient, as HJ pointed out).
> 
> Some particular targets mandate that all portions of executable segments
> (even unreachable code) be valid instructions.  Targets with such a
> requirement may vary on which, if any, trapping instructions are valid
> enough for their constraints.  The simplest, safest, and most efficient
> (for processor instruction prefetch and so forth) choice is to use nop
> instructions.  (This is not an issue of ELF or even of psABIs, it's an
> issue of particular systems.  Systems that don't care just don't care--a
> nop is as good as a zero--so it's not worth the complexity to make detail
> this more specific than per-machine.)

Looking for your original posts the target you are considering is Native
Client (NaCl).  Am I correct?

If so do you mind pointing me at some publicly available documentation
describing these constraints please?  I would like to understand why the
padding for executable segments (which should not be executed) is better to
be a no-op than an UNDEFINED instruction which is trappable.

Given that you do want the code to be executable - do you need a real no-op
in the padding?

If not then filling with zeros is probably okay.  In ARM state this is:
	andeq	r0, r0, r0
And for Thumb:
	movs	r0, r0

ARM is obviously an effective no-op, for Thumb the register file doesn't get
changed but the N and Z flags get corrupted.

I can't (currently) think of why anyone would when producing an image,
legitimately, rely on linker padding to be no-ops (or even just executable
instructions).  The ARM ABI says that functions must treat the NZCV flags as
dead on entry.  So I would argue that corrupting the N and Z flags is okay.

So in this case the simple solution to your 'are we ARM or Thumb?' issue is
just use zeros as is currently done.

Thanks,

Matt

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