Re: a question

[Daniel Jacobowitz <drow@false.org>]

On Wed, Aug 15, 2007 at 05:20:23PM -0700, Marius Nita wrote:
> I have a rather specific question regarding the code below, which is
> in bfd/aout-arm.c line 420. This code seems to deal with bit-level
> endianness. E.g. a "char" address holding a bit pattern 00010000
> represents 0x10 on one endianness and 0x08 on the other. The r_length
> left-shift below shifts data by 5 bits on big-endian and 1 bit on
> little-endian. The r_length data will end up occupying 2 bits in the
> natptr->r_type[0] byte. On big-endian, they'll be bits 6 and 7, and on
> little-endian, they are bits 2 and 3.
> 
> My question is: why aren't the bits in r_length "reversed" to conform
> with bit-level endianness? For example, if the r_length bits are "10",
> this left-shift results in "0100 0000" on big-endian and "0000 0100"
> on little-endian. These bit strings are clearly not the reverse of
> each other.

Each byte is written out, one at a time.  At that point there is no
definition of "endianness".  Bitfields are always special, since they
are at finer than byte resolution.  Try writing the obvious C struct
equivalent of the data type, and think about how it's laid out in each
endianness.

I don't want to know what you're doing that involves ARM and a.out;
whatever it is, use ELF instead :-)

-- 
Daniel Jacobowitz
CodeSourcery