2 ms·
Very cool! This looks a lot like something Michael Chastain was working on in the late 90s: http://lwn.net/1999/0121/a/mec.html http://lwn.net/1999/0121/a/mec.h
by haberman 13y ago
Very cool! This looks a lot like something Michael Chastain was working on in the late 90s: http://lwn.net/1999/0121/a/mec.html http://lwn.net/1999/0121/a/mec.html
It also is similar to GDB's record-and-reply functionality, except that I believe GDB is limited to a single process. I suspect that GDB's approach is much higher overhead also, because I think it actually records state changes for every instruction: http://sourceware.org/gdb/onlinedocs/gdb/Process-Record-and-Replay.html http://sourceware.org/gdb/onlinedocs/gdb/Process-Record-and-...
Unlike the GDB functionality, this doesn't seem to support reverse-stepping. Hopefully this can be added -- it makes a huge difference when you can reverse-step backwards from the failure to find out where things went wrong: https://sourceware.org/gdb/onlinedocs/gdb/Reverse-Execution.html#Reverse-Execution https://sourceware.org/gdb/onlinedocs/gdb/Reverse-Execution....
- Tobu 13y agoIn theory, the replayer could be made to rerecord a full memory trace. Running the replayer in gdb would be enough for a single process.
- haberman 13y ago> In theory, the replayer could be made to rerecord a full memory trace. Yes exactly, or if it's cheaper, create periodic compressed snapshots and replay from the previous one to recreate intermediate states. In my experience GDB's recording is very expensive and very rapidly runs into resource limits. Hopefully a snapshot-based approach would be more scalable.