This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bfd_arch_info.fill vs ARM (bug 13616)


On Thu, Feb 2, 2012 at 3:23 AM, Matthew Gretton-Dann
<matthew.gretton-dann@arm.com> wrote:
> Looking for your original posts the target you are considering is Native
> Client (NaCl).  Am I correct?

Yes.

> If so do you mind pointing me at some publicly available documentation
> describing these constraints please?

There is: http://dev.chromium.org/nativeclient/reference/arm-overview
Some details may be stale and it might not really explicitly cover this
question.  I'm not sure there is anything covering the Thumb variant,
which is in a much less developed state than ARM (which is not actually
in production yet either).

> 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.

The code validation is whitelist-style rather than blacklist-style.
I think it only allows one particular instruction as what's known
to trap safely.

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

No, not really.  It just needs to be something that passes validation.
Roughly, that means it should be some vanilla user instruction that is not
any kind of jump or memory access.

Of secondary concern is that it be something that won't ever make a
processor do something suboptimal like spend extra cycles on
prefetch-related work.  But that's a generic issue for any target where
some processor implementations someday might be smart enough to do some
speculative decoding or execution work but dumb enough to spend cycles on
that for code that's unreachable because it follows an unconditional jump
or trap or suchlike.  So I'd expect CPU experts to want to take care of
that issue as necessary for every target variant.

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

That's a good point.  I think these are fine.  I wasn't really thinking
about what zeros looked like to our ARM and Thumb code validators, just
following the model of using nops as we do on x86.  But on x86, zeros
encode a memory access and so are actively unsafe.

So I think this subject is in fact moot for ARM.  Thanks for helping me
figure that out.  (As a general thing, it seems not unlikely that some
target someday will want more information in this hook than just the
endianness and is-code flags, but that can be dealt with when it arises as
a concrete problem.)


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]