4 ms·

rr predates the one in gdb if I am not mistaken

• roca 2y ago
  Actually the gdb implementation predates rr, but (as an rr maintainer) I have to say that it is vastly inferior to rr. It's about 1000x slower than rr, and can't record across system calls or multiple threads or processes. It's so limited it's really a different feature.
  • ho_schi 2y ago
    Thanks. Can you explain why rr is so much more efficient?
    • roca 2y ago
      The two approaches are completely different. gdb singlesteps the program and, before each instruction, records the state of registers and memory that will be changed by that instruction --- an undo log. Then you can reverse-execute an instruction by restoring the state from the undo log. This is incredibly slow because singlestepping requires a full context switch for each instruction executed. rr, on the other hand, intercepts all system calls and other sources of nondeterminism but regular CPU instructions execute normally with no overhead. The details about rr are here: https://arxiv.org/abs/1705.05937 https://arxiv.org/abs/1705.05937
• Veserv 2y ago
  rr was introduced in 2014 [1]. gdb reverse debugging was introduced in 2009 [2]. You can see a fairly comprehensive history of time travel debugging here [3]. Not to say the built-in gdb reverse debugging was any good. It had (has?) like 1,000,000% overhead which is basically unusable. At least some implementations in the history that were introduced earlier only had ~1,000% overhead or less in general. Yes, a literal 1,000x overhead difference. [1] https://robert.ocallahan.org/2014/03/introducing-rr.html https://robert.ocallahan.org/2014/03/introducing-rr.html [2] https://www.sourceware.org/gdb/wiki/ReverseDebug https://www.sourceware.org/gdb/wiki/ReverseDebug [3] https://jakob.engbloms.se/archives/1564 https://jakob.engbloms.se/archives/1564
  • ho_schi 2y ago
    Thanks for the info and links :)