Helge Hess schrieb: > On 2. Dez 2005, at 14:50 Uhr, David Ayers wrote: > >>> It isn't neglible, its a major overhead: >>> ---snip--- >>> [EMAIL PROTECTED]:/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 >>> [EMAIL PROTECTED]:/usr/local/lib$ strip libNGObjWeb_d.so.4.5.216 >>> [EMAIL PROTECTED]:/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. _______________________________________________ Discuss-gnustep mailing list [email protected] http://lists.gnu.org/mailman/listinfo/discuss-gnustep
