Re: Endian bug disassembling SH4 code from binary ??

[armcc at lycos dot com]

----- Original Message -----
From: "Nick Clifton" <nickc@redhat.com>
To: "Mike Frysinger" <vapier@gentoo.org>
Subject: Re: Endian bug disassembling SH4 code from binary ??
Date: Mon, 09 Jan 2006 12:27:19 +0000

> 
> Hi Mike,
> 
> >>> Binutils version: 2.16.1
> >>>
> >>> $ echo -ne ".text\nnop\nnop\n" > test.S
> >>> $ sh4-linux-uclibc-as -isa=sh4 test.S -o test.o
> >>> $ sh4-linux-uclibc-objcopy -O binary test.o test.bin
> >>> $ sh4-linux-uclibc-objdump -D -m sh4 -b binary test.bin
> >>>
> >>> 00000000 <.data>:
> >>>    0:   09 00     .word 0x0900   <-- Should be 'nop' !?!
> >>>    2:   09 00     .word 0x0900   <-- Should be 'nop' !?!
> >>>
> >>>
> >>> Is this a bug, or am I missing a critical objdump option ??
> >> Normally you need to specify the endianness explicitly when using -b
> >> binary.
> >
> > shouldnt the default endian be whatever the toolchain is targeting though ?
> 
> Probably.  In fact for me it does it appear to work this way.  I 
> tried the above test and I got the correct disassembly without 
> having to put -EB on the objdump command line.  (This was using 
> today's binutils sources though, not the 2.16.1 release).
> 
> Andre - what was the endianness of the host machine you used to run 
> these tests ?  Also can you check to see if you still have the 
> problem using an objdump built from the most recent binutils 
> sources in the CVS repository ?
> 

Original host and toolchain configuration were both little endian.
After adding an explicit -EL to the objdump command line I do get the
correct disassembly.

Seems like 'objdump -b binary' defaults to big endian in all cases ??

There's no change with binutils from today's CVS.

Andre
--


-- 
_______________________________________________

Search for businesses by name, location, or phone number.  -Lycos Yellow Pages

http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10