This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [build, driver] RFC: Support compressed debug sections


>> 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?

> 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.

-eric


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]