[llvm-dev] [LLD] Should --compress_debug_sections be enabled (=zlib) by default ?
Rui Ueyama via llvm-dev
llvm-dev at lists.llvm.org
Tue May 7 00:03:00 PDT 2019
We can compress debug sections in compiler-generated object files as well
as linker-generated executables. So the question whether we should compress
debug sections is not only relevant to lld but to clang, and I think it's
actually a whole toolchain-level decision.
If we decide to compress debug sections for some target, we should make a
change to the compiler driver to flip the default for a compiler flag to
turn on compression. lld is invoked by the compiler driver, so a change for
the linker would be added to the compiler driver too.
I think I'm mildly in favor of making such change -- I guess the cost of
compress doesn't too high, and that might even make things *faster* by
reducing the amount of IO. I'd guess people wouldn't even care whether
debug sections are compressed or not, as their tools already support it.
But I don't have an evidence that the latter is actually the case.
*From: *Romain GEISSLER via llvm-dev <llvm-dev at lists.llvm.org>
*Date: *Mon, May 6, 2019 at 2:18 AM
*To: *llvm-dev at lists.llvm.org
Hi,
>
> In the file lld/ELF/Driver.cpp in function getCompressDebugSections we can
> see that the current default for lld is no debug section compression. It
> looks like tools like gdb, valgrind, elfutils, gcc's backtrace lib
> currently support compressed symbols. Since perf can use libdw from
> elfutils, I guess it supports it too.
>
> Do you think it's time to enable compressed debug section by default ? On
> some of my big binaries (several hundreds of MB) this could save 50% of the
> overall binary size.
>
> Cheers,
> Romain
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190507/0425e12e/attachment.html>
More information about the llvm-dev
mailing list