// Deterministic debugging with rr record-replay. Use when debugging crashes, ASAN faults, or when reverse execution is needed. Provides reverse-next, reverse-step, reverse-continue commands and crash trace extraction.
Provides adversarial code comprehension for security research, mapping architecture, tracing data flows, and hunting vulnerability variants to build ground-truth understanding before or alongside static analysis.
Multi-stage pipeline for validating that vulnerability findings are real, reachable, and exploitable, preventing wasted effort on hallucinated findings, dead code paths, or findings with unrealistic preconditions.
Generate, export, load, and verify forensic evidence from GitHub sources. Use when creating verifiable evidence objects from GitHub API, GH Archive, Wayback Machine, local git repositories, or security vendor reports. Handles evidence storage, querying, and re-verification against original sources.
Instrument C/C++ with -finstrument-functions for execution tracing and Perfetto visualisation
Add gcov code coverage instrumentation to C/C++ projects
Check if specific lines were executed using gcov data
| name | rr-debugger |
| description | Deterministic debugging with rr record-replay. Use when debugging crashes, ASAN faults, or when reverse execution is needed. Provides reverse-next, reverse-step, reverse-continue commands and crash trace extraction. |
| user-invocable | false |
rr provides deterministic record-replay debugging with full reverse execution capabilities.
rr record <program> [args]rr replay (enters gdb interface with reverse execution)All standard gdb commands work, plus reverse variants:
reverse-next / rn: Step back over function callsreverse-step / rs: Step back into functionsreverse-continue / rc: Continue backward to previous breakpointreverse-stepi / rsi: Step back one instructionreverse-nexti / rni: Step back over one instructionAfter rr record <crashing-program>:
rr replay
# In gdb:
reverse-next 100 # Go back 100 steps (adjust N as needed)
# Now step forward to see execution leading to crash:
next
next
...
After rr record <asan-program>:
rr replay
# In gdb:
bt # View stack trace
up # Issue "up" commands until last app frame (before ASAN runtime)
break *$pc # Set breakpoint at that location
reverse-continue # Go back to last app instruction before ASAN
# Now step forward to see execution leading to fault:
next
next
...
Standard gdb commands work at any point:
print <var>: Print variable valueprint *<ptr>: Dereference pointerx/<format> <address>: Examine memory
x/10xb <addr>: 10 bytes in hexx/s <addr>: String at addressinfo locals: Show local variablesinfo args: Show function argumentslist: Show source code around current locationdisassemble: Show assembly around current locationlayout src: TUI source viewlayout asm: TUI assembly viewset disassemble-next-line on: Show assembly with each stepUse scripts/crash_trace.py to automatically extract execution trace before crash.