<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Nov 11, 2020 at 12:19 AM Alexander Yermolovich 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">




<div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)">
<span style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255);display:inline">This year Igor Kudrin put in a lot of work in enabling DWARF64 support in LLVM. At Facebook we are looking into it as one
 of the options for handling debug information over 4gigs in production environment. One concern is that due to mix of third party libraries and llvm compiled code the final library/binary will have a mix of CU that are DWARF32/64. This is supported by DWARF
 format. With this mix it is possible that even with DWARF64 enabled one can still encounter relocation overflows errors in LLD if DWARF32 sections happen to be processed towards the end.</span><br style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255)">
<br style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255)">
<span style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255);display:inline">One proposal that was discussed in </span><a href="https://reviews.llvm.org/D87011" rel="noopener noreferrer" style="margin:0px;font-family:Calibri,sans-serif;background-color:rgb(255,255,255)" target="_blank">https://reviews.llvm.org/D87011</a><span style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255);display:inline">,
 is to modify LLD linker to arrange debug_info sections so that DWARF32 comes first, and DWARF64 after them. This way as long as DWARF32 sections don't themselves go over 4gigs, the final binary can contain debug information that
<span style="color:rgb(228,230,235);font-family:system-ui,-apple-system,system-ui,".SFNSText-Regular",sans-serif;font-size:15px;white-space:pre-wrap;background-color:rgb(62,64,66);display:inline">
exceeds</span> 4gig. Which I think will be the common case.</span><br style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255)">
<br style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255)">
<span style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255);display:inline">An alternative approach that was proposed by James Henderson is for build system to take care of it, and to use -u to enforce
 order.</span></div></div></blockquote><div><br></div><div><a class="gmail_plusreply" id="plusReplyChip-0" href="mailto:maskray@google.com" tabindex="-1">+Fangrui Song</a> here for thread visibility<br></div><div><br></div><div>Of these two approaches I think that the linker sorting is probably the one I'd go with for the reasons you list below - I'm particularly sympathetic to not wanting the unintended consequences of using -u here :)</div><div><br></div><div>I do worry about slowing down general debug links so a "debug info sorting" option may make sense, or it may not be worth it after measuring the speed difference.</div><div><br></div><div>Thanks for bringing this up on the list! :)</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0);background-color:rgb(255,255,255)"><br style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255)">
<span style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255);display:inline">As, I would imagine, most projects of scale are using configurable build system that pulls in all the various dependencies
 automatically in a multi-language environment. I think the alternative approach will be more fragile than modifying LLD as it relies on a more complex system, and each customer of LLD will have to implement this "sorting" in their own build systems. The use
 of -u also kind of abuses this flag, and might have unintended consequences. As was pointed out by Wen Lei.</span><br style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255)">
<span style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255);display:inline">From overhead perspective we only need to access few bytes of DWARF to determine if it's 32 or 64 bits. Customers who need
 DWARF64, already accept the overhead that it entails.</span><br style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255)">
<br style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255)">
<span style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255);display:inline">Any thoughts?</span><br style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255)">
<br style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255)">
<span style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255);display:inline">Thank You</span><br style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255)">
<span style="color:rgb(0,0,0);font-family:Calibri,sans-serif;background-color:rgb(255,255,255);display:inline">Alex</span><br>
</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="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div></div>