gdb stoppt nicht bei gegebenem Hardware Watchpoint mit x86 cpu

Question

Ich habe QEMU mit gdb debugged.

Um unerwartete Speicherzugriffe zu verfolgen, habe ich einen Hardware-Watchpoint auf eine bestimmte Adresse eingestellt. Gdb stoppt jedoch nicht, während der Wert in der Adresse geändert wird. Dies ist das erste Mal, dass ich die Hardware-Watchpoint-Funktion in gdb benutzt habe.

Ich weiß nicht, warum das passiert ist, und möchte dieses Problem lösen.

Das Folgen ist der gdb Konsolenausgang.

$ 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 

---

Danke, Russisch beschäftigt. Der Speicher ist User-Space und wird mit MAP_PRIVATE zugewiesen, so dass andere Programme möglicherweise den Inhalt nicht ändern. Können Sie mir alternative Tools mitteilen, um den Teil des QEMU zu finden, der den Wert ändert, oder Systemaufrufe, die in den Speicher des Benutzerspeichers schreiben können?

Answer 1

Allerdings ist gdb nicht zu stoppen, während der Wert in der Adresse geändert wird

GDB kann erkennen, wenn der Wert ändern ist, während das Programm im Userspace läuft. Es kann (und gibt nicht) vom Kernel vorgenommene Änderungen erkennen (z. B. infolge eines Systemaufrufs read(2) oder mremap(2)). Wenn die fragliche Adresse Teil einer MAP_SHARED Zuordnung ist und ein anderer Prozess den Speicher ändert, wird GDB auch nicht anhalten.

Answer 2

Versuchen Sie, Software-Watchpoints zu verwenden. Setzen Sie can-use-hw-watchpoints 0 in GDB, bevor Sie den Watchpoint setzen. Dadurch wird GDB den Wert dieser Speicheradresse nach jedem Schritt prüfen. Es wird schmerzhaft langsam, aber zumindest können Sie die unbeabsichtigte Änderung bemerken.

Es ist möglich, mehrere virtuelle Speicheradressen (möglicherweise über verschiedene Prozesse/Paging-Strukturen) auf die gleiche physikalische Speicheradresse abzubilden. Aufbauend auf das, was der diensthabende Russe gesagt hat, schätze ich, dass der Watchpoint nach Schreibvorgängen an die angegebene virtuelle Speicheradresse sucht, nicht nach der physikalischen Speicheradresse. Wenn dies der Fall ist, wird keine Schreiboperation auf eine andere Adresse des virtuellen Speichers abgefangen, die auf die gleiche physikalische Adresse verweist.