This is the mail archive of the gdb@sourceware.org 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: Using reverse execution


Eli Zaretskii wrote:

Date: Wed, 14 Sep 2005 15:34:28 -0700
From: Stan Shebs <shebs@apple.com>
Cc: gdb@sources.redhat.com

But have you actually done any debugging by reverse execution yourself?


Yes.



Cool! Care to share any details??

As a comparison, for tracepoints we came up with various scenarios for
how they would be amazingly useful and powerful, and yet after nearly
a decade they remain a curiosity in GDB.


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?
When breakpoints don't work on a platform, users don't say "oh well,
we'll just have to do without". Apparently tracepoints are just not
a must-have.

So that's the kind of question I'm asking for reverse execution - what
do we think it takes to make it useful? Do we have to be be able to
undo all system calls, or is it sufficient to just skip over them
somehow? Should executing forward after reversal re-execute system
calls, or skip over them, or should there be a sort of virtual/real
option? Do we have to be able to unroll back to the beginning of the
program, or can we usefully limit the range? Is there any more risk
to users than they incur now when calling a function in the inferior?
Reversing is likely to be slower - how much is acceptable? Will an
incomplete mechanism still be interesting, or would it get a bad
reputation such that no one will use it?


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

Stan


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