This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [discuss] Support for reverse-execution


On Sat, May 21, 2005 at 01:07:41PM +0300, Eli Zaretskii wrote:
> This leads me to another idea.  Perhaps we should implement a
> checkpointing infrastructure in GDB, and allow the user (perhaps not
> by default, but as part of some mode) to go back to every place where
> the program stopped, for whatever reason: breakpoint, watchpoint,
> single-stepping, etc.  That is, each time the inferior stops, ask the
> target for the information that fully describes its state, store that
> state description, and allow the user to rewind the target to any of
> the stored states.
> 
> I think this would be a great feature to have in all kinds of targets,
> including native, since the user can then step forward from the
> checkpoint to reach any point in between.

Two things.

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.

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.

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

And the only way that checkpointing could be as user-friendly as
stepping would be if GDB emulated the latter on the former, I think
(already suggested).

> How would this suggestion of mine map to the remote targets and
> simulators that support checkpointing on the target side?

Just fine, all it needs is bookmarking.

-- 
Daniel Jacobowitz
CodeSourcery, LLC


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]