This is the mail archive of the
mailing list for the GDB project.
Re: RFA: makes darwin-nat.c threads (and multi-processes) aware
- From: Tom Tromey <tromey at redhat dot com>
- To: Stan Shebs <stan at codesourcery dot com>
- Cc: Tristan Gingold <gingold at adacore dot com>, gdb-patches at sourceware dot org
- Date: Mon, 18 May 2009 16:54:03 -0600
- Subject: Re: RFA: makes darwin-nat.c threads (and multi-processes) aware
- References: <20090319141746.GA81236@ulanbator.act-europe.fr> <4A11BE08.email@example.com>
- Reply-to: tromey at redhat dot com
>>>>> "Stan" == Stan Shebs <firstname.lastname@example.org> 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.