CODEWITHSUNDEEP
gdbwatchpoint
nutsman
nutsman

Reputation: 361

gdb does not stop at given hardware watchpoint with x86 cpu

I have debugged QEMU with gdb.

To trace unexpected memory accesses I set a hardware watchpoint at a specific address. However, gdb does not stop while the value in the address is changed. This is the first time I have used hardware watchpoint feature in gdb.

I do not know why this happened, and would like to solve this problem.

The follow is the gdb console output.

$ gdb --args ./qemu-system-x86_64 -m 512 -hda linux-0.2.img 

...

(gdb) x 0x7fffbbe8e000
0x7fffbbe8e000: 0x00000000
(gdb) watch *(int *)0x7fffbbe8e000
Hardware watchpoint 1: *(int *)0x7fffbbe8e000
(gdb) c
Continuing.
[Thread 0x7fffc2dad700 (LWP 3162) exited]
[New Thread 0x7fffc2dad700 (LWP 3169)]
[Thread 0x7fffc2dad700 (LWP 3169) exited]
[New Thread 0x7fffc2dad700 (LWP 3173)]
qemu: /home/nutsman/git_repo/M-QEMU/qemu-2.3.1/exec.c:3007:      ldl_phys_internal: Assertion `val1 == val' failed. 

Program received signal SIGABRT, Aborted.
[Switching to Thread 0x7fffc23ca700 (LWP 3163)]
0x00007ffff61f4cc9 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56  ../nptl/sysdeps/unix/sysv/linux/raise.c: no such a file or directory

(gdb) x 0x7fffbbe8e000
0x7fffbbe8e000: 0x6c7cebfa

Thank you, Employed Russian. The memory is user-space and allocated with MAP_PRIVATE, so any other programs may not change the content of it. Can you let me know alternative tools to find the part of the QEMU which change the value, or system calls which can write to user-space memory?

Upvotes: 2

Views: 932

Answers (2)

Chester
Chester

Reputation: 11

Try using software watchpoints. Do set can-use-hw-watchpoints 0 in GDB before setting the watchpoint. That will make GDB check the value of that memory address after each step. It will be painfully slow, but at least you might catch the unintended modification.

It's possible to map multiple virtual memory addresses (possibly across different processes/paging structures) to the same physical memory address. Building off what Employed Russian said, I'm guessing that the watchpoint looks for writes to the specified virtual memory address, not the physical memory address. If that's true, it won't catch a write to a different virtual memory address that maps to the same physical address.

Upvotes: 1

Employed Russian
Employed Russian

Reputation: 213526

However, gdb does not stop while the value in the address is changed

GDB can detect when the value is change while the program is running in userspace. It can't (and doesn't) detect changes made by the kernel (e.g. as a result of read(2) or mremap(2) system call). If the address in question is part of a MAP_SHARED mapping, and some other process modifies the memory, GDB will not stop either.

Upvotes: 2

Related Questions