gdb --> Raven loading with wrong "endianness"

Have you tried 'set endian little' before talking to the target?

Tauno Voipio tauno voipio @ iki fi

Hi Tauno,

Yes, the command is is the startup file before the connection (to the driver) is made.

Some more information: I am using the OcdLibRemote driver to interface gdb to the target. Here is my .gdbinit file:

---------------------------------------------- set complaints 1 set output-radix 16 set input-radix 16 set endian little dir . set prompt (arm-gdb)

target remote 217.169.15.187:8888

monitor endian big load ./lpa2.elf symbol-file ./lpa2.elf

----------------------------------------------

(I tried all the combinations for "set endian" and "monitor endian".

I am using a "stock" gdb 5.3 built for arm-elf. I wonder, can this in fact talk properly to the OCD driver, or do I need something else?

I think the OCD Driver only works with GDB 5.0

I am still having this problem!

Some more information:

GDB uses OCDlibremote to talk to the hardware. The loading process is incorrectly inverting the "endianness", for instructions, *but not for data* !!!

How is this even possible? I suppose either gdb or OCDlibremote must be doing some "interpretation", somehow. This happens even when the input file is in a raw s-record format.

Could somebody please confirm that they have had this configuration working:

gdb -> OcdLibremote -> Raven | Wiggler -> LittleEndian ARM

If not via the newsgroup, is there anyone who would be willing to help via email? Pretty Please?

Thanks,

I have had OCDLibremote (running under Cygwin / Win2000) -> RAVEN ->

LittleEndian ARM 9 and ARM7 processors.

GDB 5.2 was running on a (different ) Linux PC.

It all worked fine.

I assume you have a cross-compiled version of GDB ?

Yes, I am using the same setup as you. OcdLibRemote on a Cygwin/W2K machine, GDB on linux. I have tried several versions of arm-elf-gdb by now, 5.0, 5.21, 5.3, mostly on linux.

Simon, thanks for the response, at least I know it should be possible!

Here is what is happening:

I have a machine code file app.sr. It is little-endian for both code and data (by inspection).

I can load app.sr using the OCD Commander debugger OK. The program stays little-endian & runs OK. I can even then connect with gdb and single step etc.

So app.sr -> OCD Commander -> Raven -> LH79520 = OK.

If I use gdb to load it, via OcdLibRemote, it inverts the endianness of the code, but not the data!

app.sr -> arm-elf-gdb -> OcdLibRemote -> Raven -> LH79520 = BAD

I don't see how this is possible, the tools should not be able to decode a hex file well enough to be able to tell the difference between opcodes and data. But this is what happens.