3 ms·

Can anyone explain how these tools work? How are they recording program execution? Don't they need to keep track of every register, memory address and such? See

• roca 8y ago
  The basic idea is that since CPUs are deterministic, if you report and replay all inputs to a process you don't have to record what goes on inside the process such as registers and memory.
• pm215 8y ago
  rr has an "extended technical report" at https://arxiv.org/pdf/1705.05937.pdf https://arxiv.org/pdf/1705.05937.pdf which explains the principles it uses. In general they are inherently rather complicated -- in order to get to anything resembling useful speed of execution, you need to play clever tricks of one kind or another to avoid having to record absolutely everything about the process under debug.
• MarkUndo 8y ago
  I think GDB's built-in record/replay mode does roughly what you describe. Tracking the effects of every instruction does is likely to give you a simpler implementation (since you just repeatedly say "next instruction, now what did that do?") but it's quite slow and can be hungry on memory, since you have to log every change. More sophisticated record/replay/reversing tools like rr provide a more sophisticated backend that doesn't need to track state per instruction. They can be much faster - and consume less memory - but more coding is required to make sure you're tracking the right state, efficiently.