This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [discuss] Support for reverse-execution
> Date: Sat, 21 May 2005 10:19:31 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: fche@redhat.com, dan@shearer.org, gdb@sources.redhat.com
>
> One, it requires extensive additional support from the target. State
> is huge and complicated - multiple threads, file system operations,
> network packets. You need a target that supports checkpointing to do
> this. I'm told there are native platforms which could offer this - I
> just don't know what any of them are.
Well, at least the Linux kernel developers could perhaps be persuaded
to add such a support.
> Two, this is basically the same thing as the bookmarking feature
> already proposed in this thread; just have GDB automatically take a
> bookmark at every stop.
Correct. What I'm saying is that by adding this we would provide a
large part of user-level functionality that is served by the full set
of reverse-* commands, but with the advantages that:
(a) the list of new commands is much smaller and thus simpler
(b) we don't need to figure out the right semantics of tricky
commands like "reverse-next" and "reverse-finish"
(c) part of the implementation is on the GDB side (as opoosed to the
target side), so it will be easier to enable it for more targets
> > If we implement something like that, perhaps we could ditch all the
> > reverse-* commands whose names we are discussing at such length in
> > this thread, and instead implement only one command, called, say,
> > "rewind" or "backup" or some such. That, and a set/show mode command
> > to enable checkpointing would be enough, I think, to have 99% of the
> > functionality originally suggested in this thread.
>
> Not at all. Here's a big use of reversible debugging: timing-sensitive
> or otherwise very hard-to-reproduce problems. You want to be able to
> leave the program running, hooked up to a simulator and a debugger, and
> then once the mysterious bug has occurred back up a little bit to see
> why.
Okay so perhaps it's less than 99%, but it's still a large portion.