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

List:       kde-core-devel
Subject:    Re: "RFC" : New kdebug/Nana
From:       Phil Maker <pjm () gnu ! org>
Date:       1999-12-19 22:15:52
[Download RAW message or body]

G'day,

On Fri, Dec 17, 1999 at 09:12:51AM -0000, David Faure sent this:
> > -----Original Message-----
> > From: jbb [mailto:jbb@ihug.co.nz]
> > Sent: Wednesday, December 15, 1999 5:56 PM
> > To: David Faure
> > Subject: RE: "RFC" : New kdebug/Nana
> > 
> > 
> > Hi David,
> > 
> > Nana's an interesting and novel approach to asserts. Wish I had thought of
> it.
> > :-) But, just reading the documents, I'd say it has some issues. Here's
> some
> > comments, in no particular order. I've only read the nana documents so I
> hope
> > these comments are accurate.
> > 
> > - It's gdb specific.
> >     although (as the author says) support for other debuggers could be
> added
> > 
> > - Currently, front end debuggers (like kdbg) wouldn't work with this
> approach

if you mean smart pretty printers/debyggers such as the DDD debugger
(which is a wonderful program) which uses gdb for all the hard work
then there is no problem. If you have your own debugger language such
as dbx then its simply a matter of adding in commands which implement:

break at file:line whenever this condition c occurs.

The main problem is that nana tends to break debuggers such 
as Codeview since they have could not (at least in the past) 
handle a signficant number of break points.

> > - Nana is more efficient than asserts.
> >     Hmmm. Is this _really_ an issue?

Typically, if you do all the assertion checking and logging you might
increase space and time costs by between say 15-35%. So it might be 
worthwhile.

> > - Macro name's are very cryptic. DS, L, I etc.
> > - You have a choice between code in program (standard assert like) or
> debugger
> >     asserts. But these macro are different for the style you want. (eg
> >     I=inline assert, DI=gdb assert) Ouch.

The recommended usage for nana is to provide a layer such as is
being discussed for kde over the top which deals with the inline/code
issue. For example KDE might decide that 90% of errors are bad 
parameters/entry conditions being violated so we will:

	Use inline asserts for checking on function entry (and always
	have them there). 

	Use debugger based asserts for checking on function exit 
	and only enable them for debugging once an error has been 
	detected.

> > - gdb style requires preprocessing the source.

Yep, you do this in your Makefile so when you recompile x.c
you would also generate the gdb scripts.

> > - dlopen'ed files could be a problem for debugger asserts.

This is normally ok as long as GDB can find the source code.

> > - getting users to give decent error reports is hard. If you went with
> debugger
> >     asserts I think it'll make the job impossible.

I think your right, I'd go with inline code for all your checking
that you want to put into the field and use the debugger stuff for
extra checking and logging for finding that little annoying
buglet.

> > I do like the idea of debugger asserts though. Perhaps just a preprocessor
> > working off the normal asserts, tt asserts and kdebug would be sufficient?

If you want to go this way just steal any bits of nana as required.

> > Of all the issues, my two main objection's to nana are
> > .. the macro names being so cryptic, and different between 
> > debugger asserts and inline asserts :(

> > If you use dbg asserts then you need to compile your code with _debug on_.
> That
> > seems to (partially) negate two points.
> > 
> > "Avoid the two executables problem (one with asserts in and another 
> > without any)."

If you use gcc -O (optimise) and -g (debug) are not incompatible so
the only real cost are the extra debug symbols in the executable. You
can get around this as well by telling gdb to use a separate file for
debug information. 

	Warning: there is a problem here, consider the following code

	int f(int i) {
		int j = 10;

		j += i;

		DI(j == 10 + i); /*assert(...)*/
		return j;
	}

	The DI doesn't work with -O since any optimiser  with 
	half a brain is going to remove j from your code and
	you cannot do assertion about objects that do not exist!

So where does that leave us?

				Bye
-- 
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]