This is the mail archive of the
mailing list for the GDB project.
gdb -> OcdLibRemote -> Raven | Wiggler -> LittleEndian Arm
- From: John Devereux <jd1 at devereux dot me dot uk>
- To: gdb at sources dot redhat dot com
- Date: 16 Sep 2003 17:38:55 +0100
- Subject: gdb -> OcdLibRemote -> Raven | Wiggler -> LittleEndian Arm
Firstly, apologies if this is off-topic for the list.
GDB loads the application into the chip with the wrong endianness!
So the instruction opcodes are all scrambled up and the program is
garbage. I have tried all four combinations of "set endian" and the
"monitor" equivalent, they seem to make no difference. (You can make
the program APPEAR correct like this, but it is still wrongly loaded
into the chip and does not run).
I am using a "raven" type JTAG device with the Sharp LH79520 (a
"little-endian" ARM variant).
I can load and run programs fine using the Macraigor OCD Commander
application. Once loaded like this, I can even use GDB to step through
the application. It is just the loading phase which is going wrong.
Can anyone shed some light on this? Is anyone doing this with a
I have currently using V5.3 of arm-elf-gdb, tried on both linux and
Some more information:
GDB uses OCDlibremote to talk to the hardware. The loading process is
incorrectly inverting the "endianness", for instructions, *but not for
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
gdb -> OcdLibremote -> Raven | Wiggler -> LittleEndian ARM