GDB 7.0, released in September 2009, was the first version to support reversible debugging. The idea is easy to state and strange to use in practice: while stepping through a program or sitting at a breakpoint, you can make execution move backward.
The commands available in GDB 7.0 cover continuing, stepping, and setting the direction of execution:
reverse-continue(rc) — continue running until a breakpoint is reached, but run the program backward.reverse-finish— run backward until execution leaves the current function.reverse-next(rn) — step backward by source line.reverse-nexti(rni) — step backward by one instruction.reverse-step(rs) — step backward by source line, entering function calls.reverse-stepi— step backward by one instruction, entering function calls.set exec-direction (forward/reverse)— set the direction of program execution.
Looking around online, I noticed that VS2010 also seemed to be preparing support for something similar. Microsoft calls it “Historical Debugging.”
For someone like me, who has been around long enough to feel old, this is both new and a little uncanny. I have not quite caught up with the technology. What is it mainly meant to do? Roll back a running program? If one statement creates a thread or a file, does reverse execution somehow reclaim the resources the program created? And even if it could, what if the program has already sent data over the network—can it take that back too? Maybe I am thinking too extreme. Still, there does not seem to be much explanation of the original need behind this feature, so I am not sure what it offers beyond being cool. Perhaps I am misunderstanding it, and I would be glad to be set straight.