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

(I had several communicating programs with real time interactions.  I
arranged for each one to spit out log lines into a separate
multilog-like program to add timestamps, and then after the fact
sorted the lines together to see what was happening.)

I can imagine an embedded system with no output facilities, where it
would be helpful to use gdb to run tracepoints over JTAG--only gdb
doesn't really support JTAG anyhow, so it still seems kind of
hypothetical.

Obviously I'm not saying that tracepoints should be removed or
anything like that.  I'm just responding to Stan's comment that
tracepoints have been around for a while and not used, by mentioning
that I personally never seen any important use for them.

Ian


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