Re: GAS compiling problem on ARM

[Nick Clifton <nickc at redhat dot com>]

Hi Mats,

>>>  AXD should know ELF endianess, it does know about target endianess,
>>>  they are both the same, and yet the op-codes are endian converted.

>>  Can you show a (small) example of this please ?

> Below is an example of how it looks like in the debugger with disassembly
> and source in mixed mode:

> 00040090    [0xe8901fff]   dcd      0xe8901fff  ....
> 101        stmia    r0,{r1-r12}
> 00040094    [0xe8801ffe]   dcd      0xe8801ffe  ....
> 102        mov    pc,lr
> 00040098    [0xe1a0f00e]   dcd      0xe1a0f00e  ....


> Here's how it looks like from objdump:
>
> ~/proj_links/mingw/cross_arm/bin/arm-elf-objdump -s testapp.axf

>  40090 ff1f90e8 fe1f80e8 0ef0a0e1 0080a0e3  ................

OK - this is a "feature" of the -s switch to objdump - it dumps the
section contents in little endian format regardless of the target's
byte ordering.

The reason is that objdump has no real way of knowing the context of
the data it is displaying (1) and so it chooses to show it in such a
way that the address of any given byte is easily deduced from its
position in the display.  ie with this line:

   40090 ff1f90e8 fe1f80e8 0ef0a0e1 0080a0e3 

The byte at address 0x40090 is 0xff.  The byte at 0x40091 is 0x1f.
The byte at address 0x40092 is 0x90.  etc.  If objdump displayed a big
endian dump:

   40090 e8901fff e8801ffe e1a0f00e e3a08000

Then the address of, say, the byte whose value is 0x1f is hard to
deduce.  It looks like it might be 0x40092 but in fact it is 0x40091.



Cheers
        Nick

(1) It can be argued that it could make a guess based on the
    attributes or name of the section it is dumping.  But even in a
    code section data can be present, and this data does not have to
    be in target-word-sized units.  The safest thing to do is to not
    assume anything about the data that is being shown and just
    display it as it is.