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?
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.