Watchpoint是监控变量或内存地址值变化的调试机制，触发条件为数据被写入（或读/写），而breakpoint在代码执行到指定行时暂停；前者绑定变量，后者绑定代码位置。
什么是 watchpoint，和 breakpoint 有什么区别
watchpoint 是 GDB 中专门用于监控内存地址值变化的断点类型，它不依赖代码行号，而是绑定到某个变量（或表达式）的内存位置。当该位置的值被写入（即修改）时，GDB 会暂停程序。这和 breakpoint 完全不同：breakpoint 在执行到某行代码时停，而 watchpoint 在某块内存被写时停——哪怕那行代码你根本没预料到会改这个变量。
常见错误现象：用 break 去“守着”一个变量赋值的地方，结果漏掉指针间接写入、数组越界覆盖、多线程并发修改等情况。这时候 watchpoint 才是真正管用的。
怎么设置变量级 watchpoint（最常用场景）
前提是变量在当前作用域可见且有确定的内存地址（不能是寄存器优化掉的局部变量，调试时建议加 -O0 -g 编译）。
- 直接对变量名设写入监控：
watch my_var - 监控结构体成员：
watch obj.count - 监控指针所指内容（注意不是指针本身）：
watch *ptr - 如果变量名被优化掉或作用域不可见，先用
print &my_var拿到地址，再用watch <em>(int</em>)0x7fff5fbff6ac（需类型强转）
注意：GDB 默认只监控“写”（watch 等价于 watch write），不监控读。如果想同时抓读写，用 awatch my_var（access watchpoint），但开销更大，某些架构不支持。
立即学习“C++免费学习笔记（深入）”；
为什么 watchpoint 没触发？常见坑和兼容性问题
- 变量被编译器优化进寄存器：
watch 失效，因为没走内存。解决方法：编译加 -O0，或在变量声明前加 volatile 强制内存访问。
- 监控全局/静态变量没问题，但局部变量离开作用域后 watchpoint 会自动删除（GDB 提示
Watchpoint X deleted）。
- 多线程下，
watch 只在触发线程停住，其他线程继续跑；若要同步暂停所有线程，确保 GDB 启动时用了 set follow-fork-mode child 和 set non-stop off（默认行为，一般不用改）。
- x86/x64 支持硬件 watchpoint（快、准），但数量有限（通常 4 个）；超出后 GDB 自动降级为软件单步扫描（极慢，甚至卡死）。可用
info watchpoints 查看当前数量和类型（hw watchpoint 或 sw watchpoint）。
watchpoint 的实际调试流程示例
watch 失效，因为没走内存。解决方法：编译加 -O0，或在变量声明前加 volatile 强制内存访问。Watchpoint X deleted）。watch 只在触发线程停住，其他线程继续跑；若要同步暂停所有线程，确保 GDB 启动时用了 set follow-fork-mode child 和 set non-stop off（默认行为，一般不用改）。info watchpoints 查看当前数量和类型（hw watchpoint 或 sw watchpoint）。比如你怀疑 buffer[10] 被意外覆写：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
启动 GDB：gdb ./myapp
运行到相关函数：break process_data → run
确认变量地址：print &buffer[10]（假设输出 0x7fff5fbff5a0）
设监控：watch *(char*)0x7fff5fbff5a0（显式类型避免歧义）
继续：continue，GDB 下次在任何写入该地址的指令处中断，并显示是哪条汇编指令干的
复杂点在于：watchpoint 本身不告诉你“谁逻辑上该负责”，只告诉你“谁物理上动了内存”。真正定位 bug 往往需要结合调用栈、寄存器状态和前后几条指令一起看——尤其是间接写入（如 memcpy、strcpy、野指针解引用）这种，堆栈可能已经跳出去好几层了。
