watch命令依赖硬件支持，仅响应写操作；rwatch捕获读取，awatch兼顾读写；watch *p监控指针所指内容，需确保p有效；监控大数组易触发软件轮询致性能骤降；局部变量watch随函数返回自动删除；须用-g编译且未strip方可生效。
watch 命令不是“设个断点就完事”，它依赖硬件支持、受变量作用域和内存布局限制，用错会静默失效或严重拖慢程序。
watch 只监控值变化，不响应读取操作
你写 watch x，GDB 只在 x 的值被**写入**（比如 x = 5、++x）时中断；如果只是 printf("%d", x) 这种纯读取，它完全不理会。
想捕获读取动作，得换命令：
-
rwatch x：只要代码里出现读x的行为（哪怕只是取地址&x），就停 -
awatch x：读或写都停，等价于rwatch+watch合体
注意：awatch 在某些旧 CPU 或虚拟机上可能降级为软件轮询，导致明显卡顿。
watch *p 和 watch p 完全是两回事
对指针 char *p：
-
watch p监控的是指针变量p自身的值（即它存的地址变了没），等价于watch *(char**)&p -
watch *p监控的是p指向的**那个字节**的内容——这才是多数人真正想要的
如果 p 是 NULL 或非法地址，watch *p 会报错：Cannot access memory at address 0x0，必须先确保 p 已有效赋值再设。
watch 数组或大内存块要小心性能陷阱
watch buf[128] 看似监控整个数组，实际 GDB 会尝试对全部 128 字节设硬件观察点。但 x86_64 通常只支持 4 个硬件观察点，且每个最多 8 字节。
结果是：
- 若超出硬件能力，GDB 自动回落到**软件轮询**（每条指令后检查内存），CPU 占用飙升，程序变龟速
- 监控
char buf[256]这种大缓冲区，基本等于放弃调试效率 - 更实用的做法是缩小范围：
watch buf[0]或watch *(int*)buf（盯住头 4 字节）
局部变量 watch 会自动删除，别指望跨函数生效
在函数内声明的变量（如 int tmp;），一旦函数返回，栈帧销毁，watch tmp 就失效。GDB 会提示：
Watchpoint 2 deleted because the program has left the block in which its expression is valid.
这种情况下：
- 不要在
main之外的函数里设 watch 后就切走，要立刻c继续并观察是否触发 - 想长期监控某数据，把它改成全局变量或
static局部变量 - 或者改用
display tmp（每次停顿时自动打印），虽然不中断，但更稳定
最常被忽略的一点：watch 生效的前提是程序已用 -g 编译，且你正在调试的是**未 strip 的可执行文件**—— stripped 二进制里没有变量符号信息，watch x 会直接报 No symbol "x" in current context。
