This is the mail archive of the
mailing list for the GDB project.
RE: [EXTERNAL] Re: Debugging big-endian ARM target from little-endian host
Yes, I am using -endian big with JLinkGDBServer
From: Simon Marchi <email@example.com>
Sent: Friday, March 1, 2019 1:54 PM
To: Jeff Wandling <JWandling@blueorigin.com>
Subject: [EXTERNAL] Re: Debugging big-endian ARM target from little-endian host
On 2019-03-01 14:45, Jeff Wandling wrote:
> -----Original Message-----
> From: Simon Marchi <firstname.lastname@example.org>
> Sent: Thursday, February 28, 2019 6:02 AM
> To: Jeff Wandling <JWandling@blueorigin.com>
> Cc: email@example.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?