Re: Using reverse execution

[Stan Shebs <shebs@apple.com>]

Michael Snyder wrote:

> Ian Lance Taylor wrote:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>
>>>> Cc: gdb@sources.redhat.com, shebs@apple.com
>>>> From: Ian Lance Taylor <ian@airs.com>
>>>> Date: 20 Sep 2005 16:13:55 -0700
>>>>
>>>> There is probably some cool use for which tracepoints are the
>>>> obvious right answer, but I don't know what it is.
>>>
>>>
>>> In native debugging, tracepoints would be very useful to debug a
>>> real-time program, or, more generally, a program where timing issues
>>> are crucial to its correct operation.  With such programs, normal GDB
>>> usage disrupts the program operation and might even cause the program
>>> to fail in ways that are unrelated to the bug you are looking for.
>>
>>
>>
>> I get that that is the idea, it's just that I wouldn't tackle that
>> problem that way.  I would put a logging framework in the program
>> itself.  That's how I've debugged this sort of issue in the past, and
>> the logging framework generally pays off for itself over time.
>
>
> That's what tracepoint debugging is, Ian -- it's a re-usable
> logging framework.  It just frees you up from having to write
> that logging code over and over into different projects, and
> recompile your project whenever you want to log something
> different.
>
> Well, that and a way-cool interactive data review and
> presentation mode.   ;-)
>
> But let's not highjack this thread to talk about tracepoints,
> unles it's to compare their use and utility to reverse execution.

Ian does touch on an important general point, which is that
debugger features ought to be uniquely available, not just
repackaging of functionality that can be accomplished nearly
as well in other ways.

For instance, when I have a plain old breakpoint that lets me stop
and interactively look at a backtrace, that is something that is
(usually) not possible to do without the help of a debugger, and
everybody agrees that this is a good feature to have.

Conversely, if I have a tracepoint that just prints out one of my
program's variables, that doesn't give me much that I can't get
with a printf. However, if the tracepoint is collecting raw
registers, that's more difficult to manage using only print
functions, and then the tracepoint starts to looks more interesting.
Ditto if I'm in a context where printf is not available, or so slow
that it affects critical real-time behavior.

In the case of reverse execution, one Appleite wondered why anybody
would bother, since you could repeatedly start the program over. And
indeed, GDB makes the restarting process pretty quick and easy; just
type "r". So reverse execution is not going to be a must-have unless
rerunning is either impossible (as in the case of intermittent bugs),
or very slow (as in the case of spending fifteen minutes giving
iTunes a particular pattern of mouse clicks and CD insertions, just
to get to the failing code).

Stan