Daniel Jacobowitz wrote:
The point of going backwards (a feature quite familiar to me from
the use of hardware debuggers on PC's in bygone years) is to figure
out what went wrong, and for that purpose you only need to worry
about the machine/memory state.
Not when you're debugging userspace and you have files.
I just don't see that at all, if you can back up to previous
memory states, where the entire machine state is reproduced
that's good enough. When you run forward from the backward
point, you just reproduce the I/O behavior that the program
execution actually saw.
You absolutely do want to insulate yourself from the external
environment when in this "backed up" mode, because, especially
in the presence of asynchronous events redoing the I/O won't
work. FOr example, if you are accessing a shared database,
then the database may change after the interruption point.
You don't want those changes to affect your attempts to find
out what went wrong.
The board I had on my PC recorded the last few thousand bus
cycles, including all I/O cycles, and simply unplayed or
replayed these from its buffer, so you were ensured that
you could exactly reproduce and replay the history leading
up to the interruption point. That's what you ideally need
for debugging.
