Re: Using reverse execution

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 14 Sep 2005 22:36:34 -0700
> From: Stan Shebs <shebs@apple.com>
> Cc: gdb@sources.redhat.com
> 
> Cool! Care to share any details??

I thought I was doing just that...

If you mean to try to answer the questions you rose, like whether to
try to undo system calls, then I'm afraid I don't remember what
happened on the system where I used such a debugger (it was quite some
time ago).

Anyway, one of the latest issues of DrDobb's ran an article about
debuggers that support similar features, with pointers to existing
products, so you could try to find them to get some ideas about
usability of this feature.

> >IMHO, tracepoints remain a curiosity because they were never
> >implemented on a large enough number of platforms.  Lack of native
> >support, in particular, is the main reason for its non-use.
> >
> But don't you think it's telling that not one single person was
> willing to go to the trouble of implementing it on more platforms?

I can only speak for myself.  You once wrote here that tracepoints in
native debugging is something to kill for, but I myself didn't have
time and resources to make that happen.

Basically, the lesson from tracepoints is, I think, that features that
GDB developers (as opposed to users) don't need too much will not
materialize.

> >We could discuss these questions one by one.  But we shouldn't fear
> >them to the degree that prevents us from starting to implement this
> >feature.
> >
> Depending on the answers, the project could be fatally flawed.

I don't think so.

> For instance, if the ability to undo system calls is critical for
> usability, that pretty much relegates reversal to simulator targets
> only - not interesting for my user base. That's why I wanted to talk
> about usage patterns; if users don't need the debugger to do the
> incredibly hard things, then we can get to something useful sooner.

I suspect that answers to most or all of your questions are
"sometimes".  I.e., sometimes the user will want to undo the system
call, and sometimes not.  I even think that sometimes they will want
to _redo_ the system call, since the bug might only happen when the
syscall is made.

This might mean we will have to put in code to ask the user what to do
with a syscall.