<div dir="ltr">Fair question - for Google, stream uncompressing to disk wouldn't help matters - disk is a ramfs, so it's the same as uncompressing the whole thing to a buffer in memory, which hurts a bit (due to memory limits).<br><br>For somewhat more "normal" users (I assume compressed debug info was probably implemented before google's needs - but I could be wrong there, maybe Google folks implemented it in gold/gcc before the LLVM switch) - especially pre-Fission, debug info was the big culprit. Though that doesn't mean it was better to just compress it rather than compressing everything. Perhaps because keeping the object file as the outer container meant more things continued to "just work" - objdump, etc, things that relied only on the object file headers and not the section contents.</div><br><div class="gmail_quote"><div dir="ltr">On Mon, Sep 17, 2018 at 4:21 PM Rui Ueyama via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ruiu added a comment.<br>
<br>
This might be a silly question, but why do we compress only debug sections? If we really want to compress object files for valid reasons (e.g. reducing amount of network traffic when doing a distributed build) we can simply compress an entire object file instead of compressing only the debug section. Then we can stream-uncompress object files to a disk and then run the linker on the input files.<br>
<br>
<br>
Repository:<br>
  rLLD LLVM Linker<br>
<br>
<a href="https://reviews.llvm.org/D52126" rel="noreferrer" target="_blank">https://reviews.llvm.org/D52126</a><br>
<br>
<br>
<br>
</blockquote></div>