I remember that -- but I never knew any details. Do you?
Did it have a fixed-size buffer for instruction trace? Did
it perform well on reverse step into/over functions? How was the speed performance?
You're right of course. It consumes tens of bytes of ram per executed instruction. But computers have gigabytes of ram these days, so it all comes down to what you consider a "usefully large" program. Millions of instructions -- no problem. Billions -- can't do that. ;-)
Yes, but AFAIK that was only for a very limited duration trace buffer. You're right, it is basically the same thing, but gdb can now do it for millions of instructions.
In fact, gdb can record the state changes and then store them into an "enhanced" core file, which can then later be used to debug the program in reverse.
It's rather like adding a "time" dimension to your core file.
;-)
No, it doesn't fork at all, it simply records the values of registers and memory that will be modified by each instruction, so that they can be restored later.
"non-stop" means that some or all of the threads in the process may be running while gdb is prompting the user for the next command. So for instance you may have one thread stop at a breakpoint, but the rest keep running.
"Multi-inferior" means you can be debugging several different processes at once. I didn't work on this one personally so I can't say much about the benefits. But the work was paid for by a contractee, so obviously somebody thinks it is better. ;-0
This is available now, in the just released gdb-7.0.
Debug any native Linux process in reverse, on x86 and
x86_64 architectures. Reverse-continue, reverse-step,
reverse-next, and so on. It's pretty fast, too!