[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: RFC: Strategy for integrating the Nana debugging library
From:       Phil Maker <pjm () gnu ! org>
Date:       1999-12-22 2:58:26
[Download RAW message or body]

On Mon, Dec 20, 1999 at 09:44:17AM -0000, David Faure wrote:
> Sure, the file and line instead of area name would better, but that's not
> the point.
> What's missing (especially for libraries) is a way to turn the debug output
> off.

Could I suggest something like the following as a method:

Each object (module, file, class or function) you want to debug declares
a static variable called logging with the appropriate scope. Then 
to enable debugging at each level in nana you use something like:

#define L_DEFAULT_GUARD (logging) /* if true we log */
#define kdebug L /* map kdebug calls to L calls (or do it properly :-) */

then in file fred.c:

static bool logging = 0;

Finally you could enable logging by using gdb with something like:

	(gdb) set "File.c"::logging = 1

If you want to get really excited you use a guard expression like:

	(filelogging || classlogging || funclogging)

Where these variables are setup with the appropriate scope.

Alternately for the non-gdb types a simple (sort-of) nm(1) based script could
be used to set the variables at start time using arguments. Perhaps 
something like:

	-d file.c 
	-d class
	-d class::method
	-d func

Sorry if the above is a bit confused or has errors but the ideas
have been used in the past and I think are in the detailed 
documentation for Nana. 

> With nana, it's really a "everything or nothing" situation
> (depending on -g). You can't turn off every lib except the one you're
> debugging,
> or turn on the lib your program is using a lot and you want to know what's
> happening in that lib, and in your program.

You can compile part of your system with -g and link it together and
everything works as expected (i.e. debugger based stuff only works
in those files compiled with -g). 

** Suggestion **
My guess is that people have a lot of different requirements, 
if people are interested I'll spend a morning this week doing up
a design of what I think I would want from this environment. 
Mostly it would pay attention to the top-level requirements such
as which things are in gdb(1) or inline code. 

So if this is worthwhile please send me your requirements, e.g.

	* I need to be able to enable/disable logging at the 
	  class level.
	* I will never ever use gdb(1).
	...

			Thanks


-- 
Phil Maker, Quoll Systems, <pjm@gnu.org>,     "Never run; once you start 
16 Bougainvillia St, Nightcliff, Darwin        running you stop thinking, 
+61 8 89854 939	work/home number.	       now remember that!" 
0409-691-399 mobile phone.		         -- Jock Lewes.
<http://www.quoll.com.au>		

[prev in list] [next in list] [prev in thread] [next in thread]