[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Enabling debug info by default (was: Re: strange NSException code)
From: |
David Ayers |
Subject: |
Enabling debug info by default (was: Re: strange NSException code) |
Date: |
Thu, 15 Dec 2005 16:18:46 +0100 |
User-agent: |
Mozilla Thunderbird 1.0.2 (X11/20051002) |
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.
- Re: strange NSException code, (continued)
- Re: strange NSException code, Helge Hess, 2005/12/01
- Re: strange NSException code, Andrew Ruder, 2005/12/01
- Re: strange NSException code, David Ayers, 2005/12/02
- Re: strange NSException code, Richard Frith-Macdonald, 2005/12/02
- Re: strange NSException code, David Ayers, 2005/12/02
- Re: strange NSException code, Lloyd Dupont, 2005/12/04
- Re: strange NSException code, Helge Hess, 2005/12/02
- Re: strange NSException code, Adrian Robert, 2005/12/02
- Re: strange NSException code, David Ayers, 2005/12/02
- Re: strange NSException code, Helge Hess, 2005/12/02
- Enabling debug info by default (was: Re: strange NSException code),
David Ayers <=
- Re: strange NSException code, Chris B. Vetter, 2005/12/02