rr是唯一真正支持可靠反向调试的工具，它通过录制非确定性输入实现精确重放，而gdb的reverse命令仅模拟反向且局限极大。
rr 是唯一真正支持反向调试的实用工具
gdb 本身不支持真正的反向执行（即倒着跑指令），它只有 reverse-step、reverse-continue 这类命令，但这些功能依赖目标程序支持精确的指令级重放——而普通 Linux 进程做不到。rr 不同：它在录制阶段完整捕获所有非确定性输入（系统调用、信号、时间等），回放时能 100% 精确复现执行路径，因此反向调试才真正可靠。
常见错误现象：gdb -ex "reverse-continue" 报错 Target child does not support reverse debugging，或看似能倒退，但变量值错乱、断点跳过、甚至直接 crash。
- 必须用
rr record ./your_program启动程序，不能 attach 已运行进程 - 录制后用
rr replay进入 gdb 环境，此时所有reverse-*命令才有效 - rr 不支持共享库热加载、fork 多进程调试较复杂（需
rr record -a录制全部子进程） - 性能开销大（录制慢 5–10 倍，磁盘占用高），只应在复现明确 bug 时启用
gdb 的 reverse-step 实际上是“模拟反向”，仅限简单场景
如果你没装 rr，又恰好遇到一个单线程、无系统调用、无浮点运算、无外部依赖的小型测试程序，gdb 的反向命令可能“看起来能用”。但这只是靠寄存器/内存快照来回滚，不是真重放。
使用场景：快速检查 for 循环里某次迭代前的变量状态，且确认循环体没调用 malloc、time、getpid 等任何系统接口。
- 启动时加
-frecord-gcc-switches和-g编译，否则reverse-step直接不可用 - 只支持
step/next的逆操作，不支持reverse-finish（gdb 12+ 才有实验性支持） - 一旦程序执行过
printf或任何 I/O，后续 reverse 很可能失败或显示脏数据 - 别指望它在优化级别
-O2下工作——调试信息和实际指令流对不上
rr 录制失败的三个高频原因
rr 对运行环境敏感，很多看似正常的程序录不了，不是你代码有问题，而是 rr 拦住了它认为“不可重放”的行为。
典型错误信息：FATAL: Cannot trace process: Operation not permitted 或 rr: Failed to open /proc/sys/kernel/yama/ptrace_scope
-
/proc/sys/kernel/yama/ptrace_scope必须为 0（Ubuntu 默认是 1），临时改用echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope - 程序用了
perf_event_open、ptrace(PTRACE_TRACEME)或自修改代码（如 JIT），rr 会拒绝录制 - 容器中运行需加
--cap-add=SYS_PTRACE，且宿主机 ptrace_scope 也得放开
反向调试真正省时间的地方：定位“谁改坏了这个变量”
比起在一堆可疑赋值点反复加断点，rr + gdb 的组合更适合解决“这个指针怎么突然变 nullptr 了”这类问题。核心思路是：先正向跑到崩溃点 → watch -l *ptr → reverse-continue → 看 gdb 自动停在最后一次写入位置。
注意：watch 在 rr 回放中是真正有效的，而在普通 gdb 中 watchpoint 反向触发基本不可靠。
- watch 表达式尽量具体，比如
watch my_obj->state比watch my_obj更稳 - 避免对 malloc 返回的堆地址做 watch，rr 对未映射内存的监控不完善
- 如果变量在内联函数里被改，确保编译时没关
-g或过度优化（-O0最保险）
rr 的反向能力只在“已录制并成功回放”的前提下成立；漏掉录制、中途 kill 掉 rr replay、或者用错了 replay session，都会让整个反向过程失效。这点容易被忽略——你以为在倒退，其实只是 gdb 在猜。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
