Re: Using reverse execution

[Stan Shebs <shebs@apple.com>]

Eli Zaretskii wrote:

>>Date: Tue, 13 Sep 2005 17:36:19 -0700
>>From: Stan Shebs <shebs@apple.com>
>>Cc: gdb@sources.redhat.com
>>
>
>>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.
>
>
But have you actually done any debugging by reverse execution yourself?
What you describe is the reason we hypothesize that reverse execution
is a useful feature, not the evidence that our users will flock to it.

As a comparison, for tracepoints we came up with various scenarios for
how they would be amazingly useful and powerful, and yet after nearly
a decade they remain a curiosity in GDB. One could argue that they're
lacking native support, or need better documentation, or whatever,
but if that's true, then the attractiveness of tracepoints depends as
much on getting those details right as on the general concept.

So that's the kind of question I'm asking for reverse execution - what
do we think it takes to make it useful? Do we have to be be able to
undo all system calls, or is it sufficient to just skip over them
somehow? Should executing forward after reversal re-execute system
calls, or skip over them, or should there be a sort of virtual/real
option? Do we have to be able to unroll back to the beginning of the
program, or can we usefully limit the range? Is there any more risk
to users than they incur now when calling a function in the inferior?
Reversing is likely to be slower - how much is acceptable? Will an
incomplete mechanism still be interesting, or would it get a bad
reputation such that no one will use it?

Stan