Reverse Debugging with GDB
Beginning with the 7.0 release in September 2009, gdb now includes support for a whole new way of debugging called "reverse debugging" -- meaning that gdb can allow you to "step" or "continue" your program backward in "time", reverting it to an earlier execution state.
Reverse debugging is only supported for a limited (but growing) number of gdb targets, including:
- Certain remote targets including the Simics and SID simulators, and "Undo-db"
The Process Record and Replay target for native linux.
Anyone who has used a debugger has probably had the experience of suddenly realizing that you have accidentally gone too far -- the event you were looking for has passed, and you missed seeing it. With reverse debugging, instead of starting the program over from the beginning and repeating your entire (possibly lengthy) debugging session, you can simply set a breakpoint at an earlier point in the program, and "reverse-continue", causing the program to back up and "undo itself" to that earlier point, from which you can proceed forward again. Or, you can "reverse-step" and "reverse-next" to back up one program statement at a time (just like normal "step" and "next" take you forward by one program statement).
Reverse Debugging Commands
Assuming you are using one of the gdb targets that supports reverse debugging (such as Process Record for Linux), you can use the following commands:
Run the program backward until it hits a stop event (such as a breakpoint, watchpoint, or exception).
Run the program backward until the beginning of the previously-executed source line.
Run the program backward for exactly one machine instruction.
Like "next" in reverse -- function calls are stepped over instead of into (in reverse).
Like "nexti" in reverse -- executes one machine instruction (backward), unles that instruction is a return from a function call, in which case the entire function will be executed in reverse.
By analogy to the "finish" command, "reverse-finish" executes the current function in reverse, until the execution reaches the calling function, then stops.