msnyder

3 ms·

1.
by msnyder 17y ago
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?
2.
by msnyder 17y ago
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 probl
3.
by msnyder 17y ago
No changes in elf or dwarf.
4.
by msnyder 17y ago
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.
5.
by msnyder 17y ago
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. ;-)
6.
by msnyder 17y ago
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.
7.
by msnyder 17y ago
Oh, and there is an online tutorial at http://sourceware.org/gdb/wiki/ProcessRecord/Tutorial
8.
by msnyder 17y ago
"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"
9.
by msnyder 17y ago
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!