Using reverse execution

[Eli Zaretskii]

> Date: Mon, 12 Sep 2005 18:17:30 -0700
> From: Stan Shebs <shebs@apple.com>
> 
> But will users actually use any of this in real life? "Undo" is pretty
> easy - everybody understands "undo", even nonprogrammers, with many
> GUIs giving it a dedicated keystroke. Tracking data backwards through
> a program is a powerful tool for a tough class of bugs, but as we know
> from past experience, powerful features that are at all hard to use
> are often ignored. Single-instruction reverse stepping is conceptually
> simpler, but likely to see more interest from the low-level
> developers, and may only be interesting if available for kernel
> debugging and the like. Reproducibility problems crop up regularly, so
> I can see people wanting to use reverse execution after a breakpoint
> sets them down in rarely-executed code.
> 
> Once we have an idea of what we think users will want from the
> feature, we'll have a better idea of what characteristics and
> limitations might be acceptable in an implementation.

You said it yourself several times: 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".

The various "undo" facilities are different: they let you correct a
mistakenly taken action.  That's not what backwards debugging is
about.

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.