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: ARM $d mapping symbol support for objdump


On Wed, 2006-11-22 at 12:02 -0500, Daniel Jacobowitz wrote:
> On Wed, Nov 15, 2006 at 06:06:19PM +0000, Richard Earnshaw wrote:
> > Incidentally, the assembler should probably have a .iword directive so
> > that we can create an entry in the code section that doesn't get marked
> > as $d.
> 
> Like so?  No docs yet; I'm not sure if this is sufficient, since
> there's no way to specify ARM-ness or Thumb-ness.  We can't use .iword
> versus .ishort, in the land of Thumb-2.  Should there be a matching
> .ishort?
> 
> Or I can just commit this without the .iword changes.

Let's separate the two issues into separate patches.  I think the $d
stuff is ok to go in.  Sorting out .iword is an independent issue whose
lack just becomes a little more obvious once we have this patch
installed.

For .iword there seem to be two ways we could go.

1) Have .iword and .ishort, where the former represents a 32-bit number,
the latter a 16-bit number.  In thumb state a 32-bit number word set
half-word1 from the most significant 16 bits of the value.
2) Have .inst and .inst.w, where the former represents a 'standard'
instruction length in the current instruction set (32-bits in arm,
16-bits in thumb); and .inst.w repreents a 'long' instruction in either
instruction set.
3) Only define .iword and have it represent a 32-bit object in arm state
and a 16-bit object in Thumb state.  32-bit Thumb-2 instructions would
then have to be created by specifying the two half-words independently.

It isn't generally very meaningful to use the same litteral values in
unified syntax, so I'm not too worried about which syntax variant we
settle on.  The one case where the encoding is identical is for
co-processor instructions, where the bit patterns for thumb-2 in
little-endian and be-8 modes come out the same as the ARM encodings due
to a trick of the encoding.

Of the three methods above, 2) is perhaps closest to the way the ARM
tools behave, but I don't personally have a strong opinion on this.

R.


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