gdb не останавливается на данной аппаратной сторожевой точке с x86 cpu

Question

Я отлаживал QEMU с gdb.

Чтобы отслеживать неожиданные обращения к памяти, я устанавливаю аппаратную точку наблюдения по определенному адресу. Однако gdb не останавливается, пока значение в адресе изменяется. Это первый раз, когда я использовал функцию сторожевого таймера в gdb.

Я не знаю, почему это произошло, и хотел бы решить эту проблему.

Ниже приведен вывод консоли gdb.

$ 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 

---

Спасибо, предприятие России. Память является пользовательским пространством и распределяется с помощью MAP_PRIVATE, поэтому любые другие программы могут не изменять ее содержимое. Можете ли вы сообщить мне альтернативные инструменты, чтобы найти часть QEMU, которые изменяют значение, или системные вызовы, которые могут записываться в память пользовательского пространства?

Answer 1

Однако, GDB не останавливается, а значение в адрес изменяется

GDB может определить, когда значение изменится в то время как программа работает в пользовательском пространстве. Он не может (и не обнаруживает) изменения, внесенные ядром (например, в результате read(2) или mremap(2) системный вызов). Если рассматриваемый адрес является частью отображения MAP_SHARED, а другой процесс изменяет память, GDB также не остановится.

Answer 2

Попробуйте использовать контрольные точки программного обеспечения. Перед установкой точки наблюдения задайте точки наблюдения-использования-hw-точки наблюдения 0 в GDB. Это заставляет GDB проверять значение этого адреса памяти после каждого шага. Это будет болезненно медленным, но по крайней мере вы можете поймать непреднамеренную модификацию.

Можно сопоставить несколько адресов виртуальной памяти (возможно, в разных процессах/структурах подкачки) к одному и тому же адресу физической памяти. Исходя из того, что сказал русский человек, я предполагаю, что точка наблюдения ищет записи на указанный адрес виртуальной памяти, а не на адрес физической памяти. Если это правда, он не поймает запись на другой адрес виртуальной памяти, который будет сопоставляться с одним и тем же физическим адресом.