Using reverse execution

[Stan Shebs]

Eli Zaretskii wrote:

> [...] looking for a bug is fundamentally
>
>a go-backward problem.  When you debug a program, you start from some
>manifestation of a bug, and mentally go backwards trying to find out
>"whodunit".
>
>
I think it's a strong and unproven claim to say that the backwards
reasoning of the mental deduction process implies that users will
find reverse execution a natural mode of debugging. For example,
imperative programming is strongly time-oriented - "do this, then
that, then the other thing". Stepping backwards from the else clause
of an if, or from a label to the goto can be kind of jarring.
Stepping backwards through an undoable operation is going to require
one to remember that the packet is not actually un-sent; multiple
backward steps (say through remote.c) could turn into a new and
unpleasant sort of memory game.

It may indeed be true that users will instantly take to reverse
execution - I believe the Simics folks have made that claim - but
I don't think we yet have enough data to justify the general
conclusion.

>The various "undo" facilities are different: they let you correct a
>mistakenly taken action.  That's not what backwards debugging is
>about.
>
>
What I'm getting at is that maybe that's the only thing users would
want to use reverse execution for. It would be ironic if we worked up
elaborate machinery, and we find users only caring about getting back
to the last checkpoint so they can try single-stepping forward again.

>The challenge is to implement going backwards in a way that won't
>overcomplicate its usage.  But I think we can manage that, if we rely
>on checkpoints and implement going backwards by unrolling to the
>previous checkpoint and then stepping forward.
>
>
That's the general implementation theory, complicated by shared
memory, thread switching, multiple CPUs, and other nasty things. :-)

Stan