Why is gdb automatically doing a read after my requested write?

Question

I'm using gdb to communicate with a LEON2-based ASIC through a home made gdb server (not sure though that "gdb server" is the correct phrase here). It works like this: the gdb client uses the ordinary gdb protocol to talk to the gdb server, which then translates the gdb requests to reads and writes from/to the HW and sends back the result to the client, if any. My gdb client is sparc-rtems-gdb 6.6 in RTEMS 4.8.0 on a Windows 7 PC.

When I start the gdb client I run the following command to attach to the gdb server:

target extended-remote localhost:5000

Then I want to change a word in RAM so I run this gdb command:

set *((unsigned int*) 0x40000000)=2

While debugging the gdb server I can see that it receives the following line, which is expected and correct according to the gdb protocol, i.e. writing 4 bytes, value 2 to address 0x40000000:

M40000000,4:00000002

Now the confusion: After the write request above, another request comes from the gdb client, read 4 bytes from address 0xABD37787:

mabd37787,4

Why is the gdb client trying to read from that address? As far as I know, I haven't done anything to request this read, I only wanted to perform the write. If gdb would have read back the address 0x40000000, for example to verify the write, it would be OK. But the out-of-nowhere-address 0xABD37787 does not exist on my HW, which causes problems for me.

Is there any way that I can debug the gdb client to determine exactly what (and why) it is sending and receiving? Or is there a setting in gdb that can explain this behaviour?

Best regards

Henrik

Answer 1

While debugging the gdb server I can see that it receives the following line

You don't need to be debugging the gdbserver. You can simply turn on set debug remote 1 in GDB, and have GDB print all sent and received packets.

Why is the gdb client trying to read from that address?

There are several possibilities:

• GDB believes that program counter is currently at 0xABD37787
• GDB believes that it needs to set a breakpoint there
• GDB believes that there is some data that it needs to read

One possible way to figure out why GDB is trying to read that location is to set debug infrun 1. This will print a lot of info about what GDB itself is trying to do.

Another way is to debug GDB itself. Put a breakpoint on putpkt, and when the packet of interest is being sent, examine the stacktrace to see why it is being sent.