[llvm-dev] [EXT] [LLD] Should --compress_debug_sections be enabled (=zlib) by default ?

Romain GEISSLER via llvm-dev llvm-dev at lists.llvm.org
Tue May 7 07:41:51 PDT 2019

Le 7 mai 2019 à 09:03, Rui Ueyama <ruiu at google.com<mailto:ruiu at google.com>> a écrit :


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 assume the compiler is clang. However in my case it would be gcc (I agree this is not a very ordinary mix of compiler/linker). When you use the full GNU toolchain, this choice of default value is done purely in binutils (you can configure it with the flag --enable-compressed-debug-sections={all,gas,gold,ld,none}).

Today as far as I know in binutils, to reduce IO, it's enabled by default in "gas" but not in "ld.bfd" (and by the way, it's not even implemented in "ld.gold", I have to submit a patch for that). This may be true for some target only, I am considering Linux x64. The fear in enabling it in "ld.bfd" is that it might break tools. For the tool I use (gdb, valgrind, (gcc) sanitizers (with gcc's libbacktrace for the stack printing)) it works. There might be other tools broken by this change. So yes it make sense to make the change at the whole toolchain level, in both the assembler + the linker. I don't know if clang uses it's own LLVM assembler or GNU gas.

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.

Ok. I will just patch lld myself then, only for my own toolchain.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190507/815a7017/attachment.html>

More information about the llvm-dev mailing list