Re: [discuss] Support for reverse-execution

[Daniel Jacobowitz <drow@false.org>]

On Sat, May 21, 2005 at 06:40:45PM +0300, Eli Zaretskii wrote:
> > 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.

Maybe.  It would be a major piece of surgery; I think that
checkpointing has been implemented before, but never merged.

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

But the new commands would be much less useful.  To me, at least.  Why
should we choose a lesser solution just to avoid figuring out the
complicated bits of a more thorough solution?

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

(c) is Paul's and Frank's point.  I think that it should wait until
there's a target that doesn't provide it on the target side; I don't
see a problem in using it if it's available.

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

Well I can't (yet!) speak from experience, but I think that you're
leaving out the most useful bits.

-- 
Daniel Jacobowitz
CodeSourcery, LLC