条件断点用break if 在指定位置满足条件时暂停，适合控制流相关场景；而监控变量被改写应优先用watch命令，它通过硬件寄存器监听内存写入，不依赖源码行，精准捕获非法修改。
怎么用 break 命令加条件捕获变量被改写
条件断点是 GDB 里最常用也最容易写错的调试手段。核心不是“能不能设”，而是条件表达式能否被 GDB 正确求值——这取决于符号信息是否完整、变量作用域是否可见、以及类型是否可解析。
假设你怀疑全局变量 g_counter 被非法修改，想在它被赋值为 42 时停住：
break counter.cpp:123 if g_counter == 42
但更可靠的做法是断在赋值语句本身（如果源码可见）：
break counter.cpp:123 if $pc == *(void**)(&g_counter + 1)
——这种写法不可靠，别照抄。真正有效的条件必须基于可求值的左值或寄存器状态。实际建议如下：
立即学习“C++免费学习笔记（深入）”；
- 优先用
watch（见下节），条件断点更适合“某行代码执行且满足某逻辑”场景，比如if user_id > 1000 && status == ACTIVE - 确保编译时带
-g -O0；-O2下变量可能被优化进寄存器，g_counter在条件里会显示为 "<optimized out></optimized>" - 条件中避免调用函数（如
if strlen(buf) > 10），GDB 默认禁用函数调用，需先执行set follow-fork-mode child和set call-on-error off，但仍有栈帧不匹配风险 - 字符串比较要用
strcmp，不能用==：正确写法是break func.cpp:45 if strcmp(name, "admin") == 0
为什么 watch 比条件断点更适合监控内存篡改
watch 是 GDB 提供的硬件辅助内存观察机制，本质是设置 x86 的 DR0–DR3 调试寄存器（或 ARM 的 DBGWCR），只要该地址被写入就触发中断——不依赖源码行、不关心控制流，对“谁改了我”这类问题精准度远超条件断点。
例如监控 g_config.flag 是否被意外置 true：
watch g_config.flag
注意这不是“当它变成 true 时停”，而是“只要这个地址被写就停”，停住后用 bt 看调用栈，用 x/i $pc 看肇事指令。
- 必须确保变量有固定地址：
watch不支持局部变量（栈地址每次运行不同）、不支持未初始化的std::vector内部缓冲区（地址会 realloc） - 硬件断点数量有限：x86-64 通常只有 4 个，
info watchpoints可查看已设数量；超出会自动降级为软件断点（轮询检查，性能极差） - 结构体成员要取地址：
watch *(int*)&g_config.flag比watch g_config.flag更稳，避免 GDB 类型解析失败导致监听失败 - 多线程下可能被其他线程触发，需配合
thread apply all bt判断上下文
awatch 和 rwatch 在什么场景下比 watch 有用
watch 只响应写操作，而 awatch（access watchpoint）响应读+写，rwatch 响应读操作。它们同样使用硬件寄存器，但触发面更广，代价是更容易误触发。
典型适用场景：
- 排查“值没变但逻辑出错”，可能是某处读了错误地址（比如指针未初始化就读）：
rwatch *0x7fffffffe000监控可疑栈地址 - 验证缓存一致性问题：多个线程反复读同一块内存，用
awatch看是否有非预期读行为 - 调试
const变量被强转修改：虽然watch能捕获写，但awatch还能提前发现非法读（比如通过const_cast后的指针读）
但要注意：rwatch 在高频读场景（如循环内读数组）会严重拖慢运行速度，GDB 每次都得拦截并判断——这不是 bug，是硬件机制决定的开销。
遇到 Cannot insert hardware breakpoint 怎么办
这个错误意味着 GDB 尝试设置硬件断点失败，常见于以下情况：
- 目标进程已用满全部调试寄存器（比如同时设了 4 个
watch，又启用了catch syscall，后者也可能占用 DR 寄存器） - 变量地址不在可监控范围内：例如
watch一个malloc返回的地址，但该内存页被标记为PROT_NONE或使用了mmap(MAP_UNINITIALIZED) - 内核禁用了用户态调试寄存器（某些容器或 hardened kernel 配置）
解决路径很直接：
先执行 info registers dr0 dr1 dr2 dr3 看当前寄存器占用；再用 delete N 清掉不用的 watchpoint；最后尝试降级为软件监控：set can-use-hw-watchpoints 0，然后重试 watch——但务必意识到：软件监控是每条指令后检查内存值，程序会慢 100 倍以上，仅用于定位，不能用于复现时序问题。
真正难的是确认篡改发生前的最后一次合法写入点——这往往需要结合 record（进程执行记录）和 reverse-step，但 record 不支持多线程和系统调用，实际项目中常受限。
