2

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

Henrik_Garbergs
  • 60
  • 6
  • What is this address? Your program's entry point by some chance? – dbrank0 Jan 12 '15 at 18:03
  • @dbrank0 The address 0xABD37787 doesn't exist in the HW memory map. RAM goes from 0x40000000 to 0x60000000. There are some registers at higher addresses, but none above the address 0xA0020000. When I'm attaching with gdb there is no program running. The CPU is in debug mode and gdb is talking to the DSU (Debug Support Unit) in the LEON2 ASIC, which can perform reads and writes in RAM and registers. – Henrik_Garbergs Jan 14 '15 at 09:04

1 Answers1

3

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.

Employed Russian
  • 199,314
  • 34
  • 295
  • 362
  • Thank you @Employeed-Russian, this was very helpful! By using the "set debug" commands that you listed I found out that the gdb client requests the value of general register (through the ´g´ request in the gdb protocol) when it connects to the gdb server. The server sends back a lot of register values, for example the content in register O7. Later when the gdb client performs a memory write, it starts by reading the address pointed out by the O7 value +8. So if the server says that O7 contains 0xABD3777F then gdb will read 0xABD37787 before writing to memory. – Henrik_Garbergs Jan 27 '15 at 20:21
  • The address O7+8 is the return address for the SW, but when I'm running gdb there has been no SW running, i.e. the O7 register can contain anything. When I started this thread I said that gdb performs this read after my write, but it appears that it occurs before the write. – Henrik_Garbergs Jan 27 '15 at 20:22
  • Does anyone know why gdb reads O7+8 before memory write, or if this behaviour can be changed? – Henrik_Garbergs Jan 27 '15 at 20:23
  • By making sure that the O7 registers in all register windows are cleared when the gdb session is started I get everything to work. I'm satisfied with this work-around. – Henrik_Garbergs May 19 '15 at 09:12