discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSProcessInfo is not initialized when debugging


From: Jeff Teunissen
Subject: Re: NSProcessInfo is not initialized when debugging
Date: Sun, 06 Jun 2004 04:34:22 -0400

Martin Kuball wrote:
> 
> Am Friday 04 June 2004 12:12 schrieb Jeff Teunissen:
> > Eric Heintzmann wrote:
> > > On 2004-06-03 13:55:24 +0200 Jeff Teunissen <deek@d2dc.net> wrote:
> > > > Adam Fedor wrote:
> > > >
> > > > [snip]
> > > >
> > > >> I think to be safe, you should only have debug versions of
> > > >> everything on non-debug versions of everything installed. Not
> > > >> both. Hopefully this
> > > >> can be fixed soon, though.
> > > >
> > > > How about just eliminating debug libs?
> > >
> > > On debian system, the GNUstep debug libs are available in
> > > separate packages, and we think this is the user who should
> > > choose if he wants to install them or not.
> > > But yes, we can explicitely remove them at build time if better.
> >
> > I mean from GNUstep, since Debian -dbg lib packages are simply the
> > regular libs, but unstripped -- which GNUstep debug libs are
> > definitely not.
> 
> I would really like to understand the implications of this. I mean
> speed, code size, and possible problems with gcc using optimization
> and debug switch at the same time.

If you expect people to be using your code in the "non-debug" version, you
should be /debugging/ that same version. The GCC optimizations do slightly
alter the code so that it's harder to follow the disassembly, but the line
number information provided by the compiler, and gdb's source display,
remain pretty accurate. However, gcc's optimizer may have bugs in it, so
disabling optimization might cause you to never see a bug that is out there
"in the field", so to speak.

In addition, setting debug=yes for -make will define the DEBUG symbol in the
compiler, and GNUstep's libs use this symbol to enable a lot of
cra^H^H^Hstuff that alters the operation of the libraries. For example, in
non-debug mode the NSDebugLog "function" does nothing, so again you're not
using the same libs -- and not debugging the same code. In effect, debug vs.
non-debug libs means that there are double the necessary number of libraries
that need debugging.

Alexander Malmberg and I both have hacked our -make packages to add -g to
the compiler's flags, and we both suggest to everyone to do the same if they
find any problems in a library. The libs run no slower, they take up no more
memory, but they use a little more disk space. No big deal.

-- 
| Jeff Teunissen  -=-  Pres., Dusk To Dawn Computing  -=-  deek @ d2dc.net
| GPG: 1024D/9840105A   7102 808A 7733 C2F3 097B  161B 9222 DAB8 9840 105A
| Core developer, The QuakeForge Project        http://www.quakeforge.net/
| Specializing in Debian GNU/Linux              http://www.d2dc.net/~deek/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]