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…
No changes in elf or dwarf.
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.
Oh, and there is an online tutorial at http://sourceware.org/gdb/wiki/ProcessRecord/Tutorial
"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…
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!
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…
No changes in elf or dwarf.
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.
Oh, and there is an online tutorial at http://sourceware.org/gdb/wiki/ProcessRecord/Tutorial
"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…
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!