Mike Stump <mikest...@comcast.net> writes:
> On Jun 3, 2014, at 3:40 AM, Rainer Orth <r...@cebitec.uni-bielefeld.de> wrote:
>> It's been another week, and I still need approval for the build, doc,
>> and Darwin changes:
>
> So, the darwin bits look trivial enough, if the entire scheme is what
> people want to do. My question would be, why do we want an option for
> this? If the scheme works, why not just turn it on unconditionally? If it
> doesn’t work, why add it? If it isn’t good, why add it? If it is good,
> why not do it?
It works in very specific circumstances, like assembler and linker versions.
> 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.
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.
I at least don't wont to patronize our users like this.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
