If you use https://pernos.co/ https://pernos.co/ then you don't need any of this, but I have a set of only slightly buggy gdbinit scripts that extend the rr deb

If you use https://pernos.co/ https://pernos.co/ then you don't need any of this, but I have a set of only slightly buggy gdbinit scripts that extend the rr debugging experience at <https://github.com/hotsphink/sfink-tools https://github.com/hotsphink/sfink-tools>. The main things it adds are: 1. a `log` command that just records whatever you give it into a plaintext file, together with its "point in time" according to rr. This is useful because when using rr, you tend to move forward and backward in time a lot, and it's hard to keep track of the actual sequence of events and where you are within them. It also creates a checkpoint so you can return to any one of your log points. It also has some niceties like replacing any expression enclosed in curly brackets with the results of executing the gdb expression given, so you can do things like log starting execution of Init() with v={v}. About to crash. 2. a `label` command that lets you assign names to random hex values. Then in the output of `p expr` or the above `log` with no arguments, which displays the full set of log messages you've recorded, it will replace known hex values with their labels. This is so much nicer than memorizing numeric values and matching them up. (rr) p obj $1 = (JSObject*) 0x7f606892a200 (rr) label OUTER_OBJ=obj (rr) p $OUTER_OBJ (JSObject*) $OUTER_OBJ (rr) log 701/31299795 [c4] starting processing with obj=(JSObject*) $OUTER_OBJ 983/31299 [c2] starting processing with obj=(JSObject*) 0x7f6068a2a200 2081/7382911 [c3] traversing to (JSObject*) 0x7f6069c2a7e8 3316/199 [c1] crashing while accessing field of object (JSObject*) $OUTER_OBJ The [c2] markers are the automatically-created checkpoints, numbered in order that you made those log entries in the debugger. It reorders the log messages to show them in execution order rather than debugging order. Pernosco has a very similar feature called the Notebook (where you only have to click on a log entry to view the state at that point in time.) The scripts are also intended for sharing log files and labels between multiple concurrent replays of the same execution, which I find useful to have separate windows each maintaining a different context (point in time, and portion of the execution that I'm examining.) That tends to be the buggier part of the scripts, though. ;-) If you're working with C or C++ (or Rust? haven't tried it), rr really is a superpower. I rarely bother using straight gdb anymore. It feels crippled.