This is the mail archive of the 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: RFA: makes darwin-nat.c threads (and multi-processes) aware

>>>>> "Stan" == Stan Shebs <> writes:

Stan> Seeing all the inferior_debug calls with different args, while I'm
Stan> working on fixing up tracepoints, gets me to thinking about whether we
Stan> can use tracepoints instead of ever-more debug printfs in GDB (looks
Stan> bad when the chefs in the kitchen send next door for takeout :-) ),
Stan> but that's a subject of its own...

I have wondered about this myself -- not using tracepoints, exactly,
but a new command implemented in Python that is basically a
combination of "break" and "printf" with an implicit "cont".

The problem I didn't know how to solve was naming the locations of the
debugging prints such that the location remains meaningful when the
source changes.  Function names work pretty well, of course, but they
are also limited when you have a very large function.

Systemtap and dtrace solve this by having users annotate their code;
the annotations turn into code that is disabled until the trace is in
effect.  We could hook into these from gdb; and then annotate gdb with
them.  If we wanted.


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