GDB remote debugging stub: Question about memory read

Niklas Quarfot Nielsen nik@qni.dk
Mon Sep 27 08:54:00 GMT 2010


Hi everyone,

I just subscribed to this list, so if I do not follow your mailing list conventions - please let me know.

I am implementing a remote debugging stub for a research operating system at the technical university of Denmark.
GDB can connect and if I disable memory reads, single stepping and hardware breakpointing works fine.  So serial communication and initialization should be in order.
The problem arises when GDB requests memory read of the stack (right after the g-packet as been received).

The registers contains the following:

rax            0x0
rbx            0xb816a
rcx            0x6e
rdx            0x8
rsi            0xffff8000000b8000
rdi            0xb8000
rbp            0xffffffff6efffff0
rsp            0xffffffff6effffd0
r8             0x5
r9             0x78bfbff
r10            0x0
r11            0x0
r12            0x0
r13            0x0
r14            0x0
r15            0x0
rip            0xffffffff80200293 <system_start+223>
eflags         0x46	[ PF ZF ]
cs             0x18
ss             0x0
ds             0x0
es             0x0
fs             0x0

GDB tries to read 0x40 bytes starting at address 0xffffffff6effffc0, which (I guess) is from the RSP.
Packet: mffffffff6effffc0,40

My question is:
Why does GDB try to read 0x40 bytes, when there is only 0x20 bytes on the stack (RBP-RSP)?

The architecture is an AMD64 and the version of GDB is 7.1(x86_64-gnu-linux).

I appreciate any answer and/or clue to why GDB behaves like this.
I have tried to look through the remote debugging source code of GDB, but this has not given me any answers.
If needed, I can post debugging information from the target code in GDB.


Best regards

Niklas Quarfot Nielsen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1925 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb/attachments/20100927/4c5a6f87/attachment.p7s>


More information about the Gdb mailing list