Re: [discuss] Support for reverse-execution

Daniel Jacobowitz
2005-05-21T17:43:42Z

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