Re: RFA: makes darwin-nat.c threads (and multi-processes) aware

[Stan Shebs <stan at codesourcery dot com>]

Tom Tromey wrote:
> > > > > > "Stan" == Stan Shebs <stan@codesourcery.com> 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.
>   
Code annotation seems reasonable for when you want data collected at 
other than the entry point.

One could even add the command itself in a comment - /* trace 
__FILE__:__LINE__ pid, kret, *addrptr */, then extract them as part of 
setting up a debugging environment.

This might be more trouble to set up than printfs, but one of the 
arguments for printfs - that they don't disrupt behavior by stopping GDB 
in time-sensitive places - goes away with nonstop. We have a 
higher-powered debugger than formerly, but we're so used to the old GDB 
that we're not yet taking advantage of all those improvements we've been 
making.

Stan