<div dir="ltr">If you're interested in things you can do in the linker for this - you might consider something more aggressive: Fully DWARF aware deduplication.<br><br>This could be done hopefully by reusing some of the code in the dsymutil implementation in LLVM.<br><br>This would be much more effective (and without the possible context-sensitive tradeoffs) than using type units. Though it'd possibly have a big tradeoff in link time and/or linker memory usage (I'm not sure how much dsymutil needs/uses of either).<br><br>It doesn't seem especially important to implement the DWARF5 types -> debug_info thing for this situation, the type units as they are (in debug_types) offer the same size benefits here. But sure, if anyone wanted to implement it at some point, that'd be fine.<br><br>I think Paul covered some of the reasons type units might not be a reasonable default.<br><br>One additional reason is that if you use Split DWARF (another great way to massively reduce the amount of debug info going to the linker) type units are mostly /just/ overhead in the .dwo files: since the debug info is not linked, there's no opportunity to remove the duplication anyway (unless you're making a DWP - like a dsym file)<br><br><div class="gmail_quote"><div dir="ltr">On Mon, Dec 4, 2017 at 7:11 AM George Rimar via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">




<div dir="ltr" style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p></p>
<div>Hi all !</div>
<div><br>
</div>
<div>We have an issue with LLD, it is  "relocation R_X86_64_32 out of range" (PR31109)</div>
<div>which occurs during resolving relocations in debug sections. It looks happens</div>
<div>because .debug_info section can be too large sometimes and 32x relocation is not enough</div>
<div>to represent the value. One of possible solutions looks to be to deduplicate information</div>
<div>to reduce .debug_info size.</div>
<div>The rest of mail contains information about experiments I did, the obtained results and</div>
<div>some questions and suggestions as well.</div>
<div><br>
</div>
<div>I was investigating idea to deduplicate debug types information. Idea is described at</div>
<div>p276 of DWARF4 specification (<a href="http://www.dwarfstd.org/doc/DWARF4.pdf" target="_blank">http://www.dwarfstd.org/doc/DWARF4.pdf</a>). It suggests</div>
<div>to split types information out of .debug_info and emit multiple .debug_types sections</div>
<div>with use of COMDATs. Both clang and gcc I tested implements -fdebug-types-section flag for that:</div>
<div><br>
</div>
<div>-fdebug-types-section, -fno-debug-types-section</div>
<div>Place debug types in their own section (ELF Only)</div>
<div>gcc's description is here: <a href="https://gcc.gnu.org/onlinedocs/gcc-6.4.0/gcc/Debugging-Options.html#Debugging-Options" target="_blank">https://gcc.gnu.org/onlinedocs/gcc-6.4.0/gcc/Debugging-Options.html#Debugging-Options</a>.</div>
<div><br>
</div>
<div>This flag is disabled by default. I compared clang binaries to see the difference<br>
</div>
<div>with and without the linker side optimisation.</div>
<div>1) Clang built with -g has size of 1.7 GB, .debug_info section size is 894.5 Mb.</div>
<div>2) Clang built with -g -fdebug-types-section has size of 1.0 GB.</div>
<div>   .debug_types size is 26.267 MB, .debug_info size is 227.7 MB.</div>
<div><br>
</div>
<div>Difference is huge and I believe shows (though probably for most of readers here it was</div>
<div>already obvious) that optimization can be useful. Though <span style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:16px;background-color:rgb(255,255,255)">
-fdebug-types-section</span> is disabled by default.</div>
<div>Looks it was initially disabled because not all of DWARF consumers were aware of .debug_types section.</div>
<div><br>
</div>
<div>Now in 2017 situation is different. I think most of DWARF consumers knows about .debug_types, but:</div>
<div>1) DWARF5 specification explicitly eliminates the .debug_types section introduced in DWARF4:</div>
<div>   p8, "1.4 Changes from Version 4 to Version 5" <a href="http://dwarfstd.org/doc/DWARF5.pdf" target="_blank">http://dwarfstd.org/doc/DWARF5.pdf</a></div>
<div>2) Instead of emiting multiple .debug_types it suggests to emit multiple .debug_info COMDAT</div>
<div>   sections. (p375, p376).</div>
<div><br>
</div>
<div>And it seems currently there is no way to make clang to emit multiple .debug_info with type information</div>
<div>like DWARF5 suggests. I tried command line below:</div>
<div>-g -fdebug-types-section -gdwarf-5</div>
<div>It still emits .debug_types and does not look there is a flag for emiting multiple .debug_info.</div>
<div>Looking at whole LLVM code (lib/mc, lib/CodeGen) actually it seems it is just always assumed .debug_info is</div>
<div>a unique section in object.</div>
<div>(also not sure why clang emits .debug_types when -gdwarf-5 flag is set, as this section is incompatible with v5,</div>
<div>probably it is a bug).</div>
<div><br>
</div>
<div>So my questions are following:</div>
<div>1) Do we want to try to implement multiple .debug_info approach ? As it seems can be very useful sometimes.</div>
<div>2) For now in LLD may be we may want to extend our error message from "relocation X out of range" to something</div>
<div>   suggesting to use -fdebug-types-section (only for relocations in debug sections) ?</div>
<div>3) Why -fdebug-types-section is disabled by default ?<br>
</div>
<p>​<br>
</p>
<div id="m_4836951543035725008Signature">
<div name="divtagdefaultwrapper">
<div class="m_4836951543035725008BodyFragment"><font size="2">
<div class="m_4836951543035725008PlainText">Best regards,<br>
George | Developer | <span style="background-color:rgb(255,255,255);color:rgb(33,33,33);font-family:Calibri,sans-serif;font-size:13.3333px">Access Softek, Inc</span></div>
</font></div>
</div>
</div>
</div>

_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>