This is the mail archive of the
gdb@sourceware.org
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
-----Original Message-----
From: Simon Marchi <simon.marchi@polymtl.ca>
Sent: Friday, March 1, 2019 1:54 PM
To: Jeff Wandling <JWandling@blueorigin.com>
Cc: gdb@sourceware.org
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 <simon.marchi@polymtl.ca>
> Sent: Thursday, February 28, 2019 6:02 AM
> To: Jeff Wandling <JWandling@blueorigin.com>
> Cc: gdb@sourceware.org
> Subject: Re: Debugging big-endian ARM target from little-endian host
>
> <simon>
> 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
> with
> x86-64:
>
> Sending packet: $vCont;c:p209a.-1#da...Packet received:
> T05swbreak:;06:10ddffffff7f0000;07:10ddffffff7f0000;10:0c4655555555000
> 0;thread:p209a.209a;core:0;
>
> 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.
> </simon>
>
> Results:
>
> https://gist.github.com/jwandblue/e1ede3f41a4e7effa7e80d5066c96724
>
> 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:
40000000
48ffffff
00000000
01000000
00000000
00000000
00000000
3f010008
314d8952
c1444c00
516c228d
16acb100
917c4ca8
00010180
08000000
b0120000 <--- Probably PC
9b030000
db030000
db030000
...
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?
Simon