On Thu, Jun 26, 2014 at 6:32 AM, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote: > 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 >
Very true. Maybe make it a -gcompress-dwarf-sections? > * 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 ;-) > The assembler itself does, but as far as I know none of the consumers can deal with it. Right now it supports the same options as gas. >>> 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 ;-( > I'd have thought you'd still largely be write bound for compilation. *shrug* > But yes, a configure option to default -gz to on would certainly be > helpful at some point. *nod* -eric
