GDB设置watch断点后地址值变更未触发中断问题求助

问题场景 #

我在调试进程时给地址0x60c010设置了硬件watchpoint，本想在该地址值变更时触发中断，但调用memset修改值后，断点完全没反应。操作流程如下：

初始查看内存值 #

(gdb) x/s 0x60c010
0x60c010:       "aaaaa"

设置硬件监视断点及触发命令 #

(gdb) watch *0x60c010
Hardware watchpoint 2: *0x60c010
(gdb) commands
Type commands for breakpoint(s) 2, one per line.
End with a line saying just "end".
>echo "changed!!!!"
>end

确认断点状态 #

(gdb) info breakpoints
Num     Type           Disp Enb Address            What
2       hw watchpoint  keep y                      *0x60c010
        echo "changed!!!!"

尝试修改内存值 #

(gdb) p (void*)memset(0x60c010,'c',5)
$2 = (void *) 0x60c010

确认内存值已变更 #

(gdb) x/s 0x60c010
0x60c010:       "ccccc"

问题：明明内存值已经变了，watchpoint却没触发进程中断。

原因分析 #

用p (void*)memset(...)在GDB命令行直接执行时，这个memset调用是在GDB自身的进程空间里跑的，不是在你正在调试的目标进程里。内存修改根本没发生在目标进程中，自然不会触发目标进程的硬件监视断点。

解决办法 #

要让内存修改操作发生在目标进程的地址空间里，有两种简单可行的方式：

方式1：用set命令直接修改内存 #

针对字符串这种固定长度的内存块，直接用set命令覆盖最直接：

(gdb) set {char[6]}0x60c010 = "ccccc"

执行这条命令后，watchpoint会立刻触发，输出预设的changed!!!!并中断进程。

方式2：用call命令让目标进程执行函数 #

如果必须调用memset这类函数，改用call命令，它会让被调试的目标进程执行该函数：

(gdb) call memset(0x60c010, 'c', 5)

这样内存修改发生在目标进程内，watchpoint会正常触发中断。

验证结果 #

执行上述任一正确操作后，GDB会输出类似内容，进程被成功中断：

Hardware watchpoint 2: *0x60c010

Old value = 97 'a'
New value = 99 'c'
changed!!!!

内容的提问来源于stack exchange，提问作者python3.789