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] |
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |