Eric Christopher <echri...@gmail.com> writes:
>>> If it is just to reach compatibility with the debugger, then I’d rather
>>> either just mandate a certain debugger or autoconf for what the current
>>> debugger supports. As of late people seem to just break the debugging
>>> experience with non-updated gdbs and assume that a newer gdb is used.
>>
>> You cannot do that: unlike the assembler and linker used, which are
>> often hardcoded into gcc, the debugger can easily be changed below the
>> compiler's feet, so to speak. Besides, on several platforms, you have
>> more than one debugger available (like gdb and dbx, or others), so this
>> isn't an option. Apart from that, the debugging experience when
>> e.g. emitting very recent DWARF extensions and trying to use them with a
>> gdb that doesn't understand them usually leads to some debug info
>> missing. In this case, emitting compressed debug with a debugger that
>> cannot read it leads to the debugger claiming (correctly, from its
>> point of view) that there's no debugging info present. I don't want to
>> tell users who come complaining `I compiled with -g, but my debugger
>> tells me there's no debug info present': `look, your debugger lies, it
>> is present, but it cannot read it'. That's a lot worse than the
>> DWARF extensions scenario above.
>
> Agreed :)
>
> FWIW it's already a gas/assembler option, I'm curious about wanting to
> expose it via the compiler?
One reason: ease of use:
* -gz is far easier to use/type than -Wa,--compress-debug-sections +
-Wl,--compress-debug-sections, and
* one common option irrespective of assemblers (the Solaris assembler
will gain eventually gain compressed debug support, too) and linkers
used (Solaris ld requires -z compress-sections=<type>), and even the
Apple assembler might at some point ;-)
>> On top of all that, compressed debug is a tradeoff: in some cases it may
>> be worth it to save space on debug info if disk space is at a premium
>> for some reason (e.g. for release builds), but in others you want to
>> compile as fast as possible, but assembling and linking compressed debug
>> takes more CPU time. Otherwise we could just as well default to -Os,
>> telling our users it's better for them since it generates faster and
>> smaller code, not minding the compile time cost and worse debugging
>> experience.
>
> FWIW I've found in some limited timing that compression is nearly
> always worth it here at Google - even for compile time given the cost
> of writing files versus cpu time. Might be worth making it a default
> at some point in the future and making sure the option is invertible.
One might be not so lucky with different/slower CPUs, though. I wonder
how this would affect bootstrap times on my current SPARC systems ;-(
But yes, a configure option to default -gz to on would certainly be
helpful at some point.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
