This is the mail archive of the
mailing list for the GDB project.
Re: Debugging big-endian ARM target from little-endian host
- From: Simon Marchi <simon dot marchi at polymtl dot ca>
- To: Jeff Wandling <JWandling at blueorigin dot com>
- Cc: gdb at sourceware dot org
- Date: Fri, 01 Mar 2019 16:54:13 -0500
- Subject: Re: Debugging big-endian ARM target from little-endian host
- References: <firstname.lastname@example.org> <672b1bfc87164c27a6a3e655eec6d813@MAIL01.blueorigin.com>
On 2019-03-01 14:45, Jeff Wandling wrote:
From: Simon Marchi <email@example.com>
Sent: Thursday, February 28, 2019 6:02 AM
To: Jeff Wandling <JWandling@blueorigin.com>
Subject: Re: Debugging big-endian ARM target from little-endian host
Do "set debug remote 1" and then "continue" so that you hit your
breakpoint. Towards the end of the debug output, you should see a
vCont;c packet, with a "stop reply" packet (assuming JLink supports
the vCont packet, and you use the all-stop mode). Here's an example
Sending packet: $vCont;c:p209a.-1#da...Packet received:
In the response, you can see a few pairs of register number/register
values. Since you know the PC you expect your program to stop at, it
should be fairly easy to spot the PC register. The value should be in
big endian, in your case. In my case, 10:0c46555555550000 corresponds
to the PC value in little endian:
(gdb) p $pc
$1 = (void (*)()) 0x55555555460c <main+4>
If you have trouble interpreting the debug remote output, pastebin it
and send the link.
The interesting result was the JLinkGDBServer doesn't emit the "vCont"
packet unless I am misreading the result.
I'm boxed into a corner since I have a SEGGER JLink dongol and so
choosing to use JLinkGDBServer is not arbitrary.
Ok, so it just seems that this "gdbserver" implementation doesn't
support vCont, so GDB uses the older 'c' packet. It should not change
anything for your endianness problem.
The registers are read using the 'g' packet, just after the 'c'. I
don't know the exact register layout for your architecture, but let's
just split the result in groups of 4 bytes:
b0120000 <--- Probably PC
So it looks like jlinkgdbserver sends you the registers in the wrong
endianness, if I understand correctly. Googling around, there seems to
be an -endian flag to pass to jlinkgdbserver. Are you using it?