This is the mail archive of the
mailing list for the binutils project.
Re: bfd_arch_info.fill vs ARM (bug 13616)
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.
Principal Engineer, PD Software, ARM Ltd.