Enabling debug info by default (was: Re: strange NSException code)

[David Ayers]

Helge Hess schrieb:
> On 2. Dez 2005, at 14:50 Uhr, David Ayers wrote:
> 
>>> It isn't neglible, its a major overhead:
>>> ---snip---
>>> helge@move:/usr/local/lib$ ls -hla libNGObjWeb_d.so.4.5.216
>>> -rwxr-xr-x  1 helge dev 5.9M Nov 29 21:22 libNGObjWeb_d.so.4.5.216
>>> helge@move:/usr/local/lib$ strip libNGObjWeb_d.so.4.5.216
>>> helge@move:/usr/local/lib$ ls -hla libNGObjWeb_d.so.4.5.216
>>> -rwxr-xr-x  1 helge dev 2.2M Dec  2 13:09 libNGObjWeb_d.so.4.5.216
>>> ---snap--
>>> Remember that this is not only on-disk, but also loaded into RAM
>>> (though only once for shared libraries like gstep-base).
>>
>> Are you sure about this? For which platform? OS X?
>> AFAIK this is not loaded into memory until accessed with even 
>> moderately recent platforms.
> 
> 
> I'm not perfectly sure about this (my assumption is/was that this is 
> true for Linux and OSX).
> Hm, can you directly memory map a shared library for execution? Of 
> course this would be rather cool. Do you have pointers for the  "AFAIK"?
> ;-)
> 

Well I've googled a bit and asked around but I haven't found an
authoritative document precisely stating for which platforms debug
information may or may not be loaded.  Yet clearly ELF defines headers
to determine what is loaded and debug information is not.  (The ELF spec
only says the the content of the debug section is unspecified as it can
have differing formats).  What I can offer is:

$ size Source/shared_debug_obj/libgnustep-base_d.so
   text    data     bss     dec     hex filename
2941620  265928    7452 3215000  310e98
Source/shared_debug_obj/libgnustep-base_d.so
$ size Source/shared_obj/libgnustep-base.so
   text    data     bss     dec     hex filename
2850643  265784    4732 3121159  2fa007 Source/shared_obj/libgnustep-base.so

(see also readelf -l)

$ ls -l Source/shared_debug_obj/libgnustep-base_d.so.1.11.1
-rwxr-xr-x  1 ayers ayers 9224333 2005-12-11 15:05
Source/shared_debug_obj/libgnustep-base_d.so.1.11.1
$ ls -l Source/shared_obj/libgnustep-base.so.1.11.1
-rwxr-xr-x  1 ayers ayers 3867641 2005-12-15 15:22
Source/shared_obj/libgnustep-base.so.1.11.1

$ size Source/shared_obj/libgnustep-base.so.1.11.1
   text    data     bss     dec     hex filename
2850643  265784    4732 3121159  2fa007
Source/shared_obj/libgnustep-base.so.1.11.1
$ size Source/shared_debug_obj/libgnustep-base_d.so.1.11.1
   text    data     bss     dec     hex filename
2941620  265928    7452 3215000  310e98
Source/shared_debug_obj/libgnustep-base_d.so.1.11.1

you can also analyze the readelf -l output on ELF systems.

And here's unofficial quote from a GDB developer:

> Debug info will have absolutely no effect, barring compiler bugs, on the 
> generated code or runtime footprint.
> I don't know an authoritative source but any toolchain which does not honor 
> this property is _broken_.
> [...] any halfway modern platform memory maps shared libraries.

That said, I think the only issue wrt to enabling '-g' is disk space.
Personally I think we may want to disable debug-info for releases,
though I personally wouldn't mind if we didn't.

Cheers,
David

PS: I suppose differences in the size output are due to:
Source/NSException.m:#ifdef     DEBUG
Source/NSException.m:#if defined(__WIN32__) && defined(DEBUG)
Source/NSException.m:#if defined(DEBUG)
Source/NSNotificationCenter.m:#if       defined(DEBUG)
and/or optimization level.