[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:       David Faure <David.Faure () cramersystems ! com>
Date:       1999-12-22 9:00:18
[Download RAW message or body]


> 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

Thanks for your proposal to improve nana.
But all this would only make sense if we didn't have kdebug, IMO.
Please take a look at the new kdebug (I finished it yesterday),
for instance just reading the new kdebug.h and launching kdebugdialog.
You'll see that it features much more than "log on/log off".
As kdebug always did, you can choose where to log what, on a severity
basis (info,warning,error,fatal).
Furthermore, the difference with the approach above is that the code doesn't
have to care about those settings, it's all handled by kdebug.
All the code has to know is a debug area code, or it can even skip that.
And all this is designed so that users (the ones that use snapshots) and
developers 
can both see the debug output - very useful when reporting bugs, so it
doesn't require
-g nor gdb.

Don't get me wrong. I'm happy to use nana for assertions, for instance.
(I'll look into that more today).
And having kdebug as handler for nana messages, as Mirko suggested, seems a
good idea.
But I really vote against #define kdebug L. We'd lose a lot.

And I think using a dialog box to dynamically change the way debug messages
are handled
is IMO a lot nicer than some sort of (non-portable) nm script :-)

--
David Faure
faure@kde.org - KDE developer
david@mandrakesoft.com - Mandrake
david.faure@cramersystems.com - Cramer Systems

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