Using reverse execution

[Eli Zaretskii]

> Date: Tue, 13 Sep 2005 17:36:19 -0700
> From: Stan Shebs <shebs@apple.com>
> Cc: gdb@sources.redhat.com
> 
> 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.

I find this natural to the degree that it doesn't need any proof.

> Stepping backwards from the else clause
> of an if, or from a label to the goto can be kind of jarring.

That's not what you do when you trace a bug.  You start from the place
where, e.g., the program gets a SIGSEGV, and then unroll it back to
possible places where the corruption could have happened.  That is,
you try to guess where the problem could have originated from, and
then get there and look around for clues.  I don't find this jarring
in any way.

> >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. :-)

Life is full of complications.  That doesn't mean we should do
nothing, just that we should understand the limitations.