This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Using reverse execution
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Stan Shebs <shebs at apple dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 13 Sep 2005 06:42:19 +0300
- Subject: Re: Using reverse execution
- References: <432628AA.2040808@apple.com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> 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.