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


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


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