<div dir="ltr">Keeping .eh_frame separated should still simplifies the linker because until the last step of building .eh_frame and .eh_frame_hdr, we don't really need to parse .eh_frame sections. So, if we have separate .eh_frame sections on -ffunction-sections, all we have to do is (1) garbage-collect sections and (2) construct .eh_frame and .eh_frame_hdr sections from live .eh_frame sections. At step 1, .eh_frame can be handled as a blob of data. That is much simpler than (1) parsing all .eh_frame sections beforehand, (2) garbage-collect .eh_frame shards, and (3) re-construct .eh_frame and .eh_frame_hdr from .eh_frame shards.<div><br></div><div>In addition to that, keeping .eh_frame separated should greatly simplifies the logic of identical code folding when comparing not only function contents but exception handler information.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 10, 2017 at 11:23 PM, Igor Kudrin via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><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>On the other hand, in this case, you have to deal with lots of small sections. I can't say for sure, which variant is quicker. Anyway, lld doesn't do deep parsing of .eh_frame sections currently, nor need it for GC. Just splits them into FDEs and CIEs and
then analyzes corresponding relocations. Thus, the amount of required work is more or less the same, whether we have separate sections or have to split the monolithic one.<br>
</p><span class="">
<p><br>
</p>
<div id="m_2789922153374009357Signature">
<div name="divtagdefaultwrapper">
<div style="color:rgb(33,33,33);font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif;font-size:15px;background-color:rgb(255,255,255);margin:0px">
<span style="font-size:10.5pt;font-family:Calibri,sans-serif">Best Regards,</span></div>
<div style="color:rgb(33,33,33);font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif;font-size:15px;background-color:rgb(255,255,255);margin:0px">
<font face="Calibri,sans-serif" size="2"><span style="font-size:11pt"><font size="2"><span lang="en-US" style="font-size:10.5pt">Igor Kudrin</span></font></span></font></div>
<div style="color:rgb(33,33,33);font-family:"Segoe UI","Segoe WP","Segoe UI WPC",Tahoma,Arial,sans-serif;font-size:15px;background-color:rgb(255,255,255);margin:0px">
<font face="Calibri,sans-serif" size="2"><span style="font-size:11pt"><font size="2"><span lang="en-US" style="font-size:10.5pt">C++ Developer,</span></font></span></font><span style="font-family:Calibri,sans-serif;font-size:14.6667px"> </span><span style="font-family:Calibri,sans-serif;font-size:14.6667px">Access
Softek, Inc.</span></div>
</div>
</div>
</span><div style="color:rgb(33,33,33)">
<hr style="display:inline-block;width:98%">
<div id="m_2789922153374009357divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> Evgeny Astigeevich <<a href="mailto:Evgeny.Astigeevich@arm.com" target="_blank">Evgeny.Astigeevich@arm.com</a>><br>
<b>Sent:</b> Friday, November 10, 2017 8:27 PM<br>
<b>To:</b> Igor Kudrin<br>
<b>Cc:</b> nd; <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><div><div class="h5"><br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Making .eh_frame more linker-friendly</div></div></font>
<div> </div>
</div><div><div class="h5">
<div>
<div class="m_2789922153374009357WordSection1">
<p class="MsoNormal" style="background:white"><span style="color:#212121">> But if we still need to deal with CIEs and generate .eh_frame_hdr in a special way,</span></p>
<p class="MsoNormal" style="background:white"><span style="color:#212121">> does it make sense to make this change to simplify only a small part of a linker?</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>For huge C++ projects this could improve link time if GC is a bottleneck. It will also improve eh_frame_hdr build time because you don’t spend time on parsing garbage. However a linker will have to have two versions of GC:
one with parsing eh_frames and another without parsing. There can be input object files where .eh_frame is not split.
</span></p>
<p class="MsoNormal"><span> </span></p>
<p class="MsoNormal"><span>-Evgeny</span></p>
<p class="MsoNormal"><span> </span></p>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span>
</b><span style="font-size:12.0pt;color:black">Igor Kudrin <<a href="mailto:ikudrin@accesssoftek.com" target="_blank">ikudrin@accesssoftek.com</a>><br>
<b>Date: </b>Friday, 10 November 2017 at 12:23<br>
<b>To: </b>Evgeny Astigeevich <<a href="mailto:Evgeny.Astigeevich@arm.com" target="_blank">Evgeny.Astigeevich@arm.com</a>><br>
<b>Cc: </b>nd <<a href="mailto:nd@arm.com" target="_blank">nd@arm.com</a>>, "<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Subject: </b>Re: [llvm-dev] [RFC] Making .eh_frame more linker-friendly</span></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<p>Hi Evgeny,</p>
<p> </p>
<p class="MsoNormal" style="background:white"><span style="color:#212121">> Yes, a linker needs some details but not all of them. It needs to know sizes of records and initial locations (PC Begin) to find out which functions FDEs belong to.</span></p>
<div>
<p class="MsoNormal"><br>
So, it still needs some details. Not all of them, but anyway, handling of .eh_frame sections is still a special case, even if we split all the content at compile time.</p>
</div>
<p> </p>
<p class="MsoNormal" style="background:white"><span style="color:#212121">> What do you mean “one place or two”?</span></p>
<p class="MsoNormal" style="background:white"><span style="color:#212121"> </span></p>
<p class="MsoNormal" style="background:white"><span style="color:#212121">If I understand it right, the RFC is about helping a linker to eliminate unneeded .eh_frame items when performing GC. But if we still need to deal with CIEs and generate .eh_frame_hdr
in a special way, does it make sense to make this change to simplify only a small part of a linker?</span></p>
<p class="MsoNormal" style="background:white"><span style="color:#212121"> </span></p>
<div id="m_2789922153374009357Signature">
<div name="divtagdefaultwrapper">
<div>
<p class="MsoNormal" style="background:white"><span style="font-size:10.5pt;color:#212121">Best Regards,</span><span style="font-size:11.5pt;font-family:"Tahoma",sans-serif;color:#212121"></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span lang="EN-US" style="font-size:10.5pt;color:#212121">Igor Kudrin</span><span style="font-size:11.5pt;font-family:"Tahoma",sans-serif;color:#212121"></span></p>
</div>
<div>
<p class="MsoNormal" style="background:white"><span lang="EN-US" style="font-size:10.5pt;color:#212121">C++ Developer,</span><span style="color:#212121"> Access Softek, Inc.</span><span style="font-size:11.5pt;font-family:"Tahoma",sans-serif;color:#212121"></span></p>
</div>
</div>
</div>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><span style="color:#212121">
<hr size="2" width="98%" align="center">
</span></div>
<div id="m_2789922153374009357divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span style="color:black"> llvm-dev <<a href="mailto:llvm-dev-bounces@lists.llvm.org" target="_blank">llvm-dev-bounces@lists.llvm.<wbr>org</a>> on behalf of Evgeny Astigeevich via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>><br>
<b>Sent:</b> Friday, November 10, 2017 6:41 PM<br>
<b>To:</b> Igor Kudrin<br>
<b>Cc:</b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>; nd<br>
<b>Subject:</b> Re: [llvm-dev] [RFC] Making .eh_frame more linker-friendly</span><span style="color:#212121">
</span></p>
<div>
<p class="MsoNormal"><span style="color:#212121"> </span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="color:#212121">Hi Igor,</span></p>
<p class="MsoNormal"><span style="color:#212121"> </span></p>
<p class="MsoNormal"><span style="color:#212121">> It sounds like the linker has to be aware of the .eh_frame section details to be able to generate .eh_frame_hdr and eliminate duplicate CIEs, right?</span></p>
<p class="MsoNormal"><span style="color:#212121"> </span></p>
<p class="MsoNormal"><span style="color:#212121">Yes, a linker needs some details but not all of them. It needs to know sizes of records and initial locations (PC Begin) to find out which functions FDEs belong to.</span></p>
<p class="MsoNormal"><span style="color:#212121"> </span></p>
<p class="MsoNormal"><span style="color:#212121">> So, is there any difference whether it knows that in one place or two?</span></p>
<p class="MsoNormal"><span style="color:#212121"> </span></p>
<p class="MsoNormal"><span style="color:#212121">What do you mean “one place or two”? If .eh_frame_hdr is not created a linker does not need to parse .eh_frame sections. It simply merges them into one section. The format of .eh_frame allows to do this without
parsing .eh_frame sections.</span></p>
<p class="MsoNormal"><span style="color:#212121"> </span></p>
<p class="MsoNormal"><span style="color:#212121">Thanks,</span></p>
<p class="MsoNormal"><span style="color:#212121">Evgeny Astigeevich</span></p>
<p class="MsoNormal"><span style="color:#212121"> </span></p>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span>
</b><span style="font-size:12.0pt;color:black">Igor Kudrin <<a href="mailto:ikudrin.dev@gmail.com" target="_blank">ikudrin.dev@gmail.com</a>><br>
<b>Date: </b>Thursday, 9 November 2017 at 11:29<br>
<b>To: </b>Rui Ueyama <<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>>, Evgeny Astigeevich <<a href="mailto:Evgeny.Astigeevich@arm.com" target="_blank">Evgeny.Astigeevich@arm.com</a>><br>
<b>Cc: </b>"<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>" <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>>, nd <<a href="mailto:nd@arm.com" target="_blank">nd@arm.com</a>><br>
<b>Subject: </b>Re: [llvm-dev] [RFC] Making .eh_frame more linker-friendly</span><span style="color:#212121"></span></p>
</div>
<div>
<p class="MsoNormal"><span style="color:#212121"> </span></p>
</div>
<p><a name="m_2789922153374009357__MailOriginalBody"><span style="color:#212121">It sounds like the linker has to be aware of the .eh_frame section details to be able to generate .eh_frame_hdr and eliminate duplicate CIEs, right?</span></a></p>
<p><span><span style="color:#212121">So, is there any difference whether it knows that in one place or two?</span></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span><span style="color:#212121">Best Regards,<br>
Igor Kudrin<br>
C++ Developer, Access Softek, Inc.</span></span></p>
<div>
<p class="MsoNormal"><span><span style="color:#212121">On 27-Oct-17 3:43, Rui Ueyama via llvm-dev wrote:</span></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<div>
<p class="MsoNormal"><span><span style="color:#212121">On Thu, Oct 26, 2017 at 1:13 PM, Evgeny Astigeevich <</span></span><a href="mailto:Evgeny.Astigeevich@arm.com" target="_blank"><span>Evgeny.Astigeevich@arm.com</span><span></span></a><span><span style="color:#212121">>
wrote:</span></span></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span><span style="color:#212121">Hi,</span></span></p>
<p class="MsoNormal"><span><span style="color:#212121"> </span></span></p>
<p class="MsoNormal"><span><span style="color:#212121">There will be problems with eh_frame_hdr. Eh_frame_hdr is needed to use the binary search instead of the linear search. Having eh_frame per a function will cause no eh_frame_hdr or multiple eh_frame_hdr
and will degrade search from binary to linear.</span></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span><span style="color:#212121"> </span></span></p>
</div>
<div>
<p class="MsoNormal"><span><span style="color:#212121">Linkers would combine .eh_frame sections into one .eh_frame, so that's not an issue, no?</span></span></p>
</div>
<div>
<p class="MsoNormal"><span><span style="color:#212121"> </span></span></p>
</div>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span><span style="color:#212121">As we create eh_frame_hdr in most cases there is no problem to filter out garbage eh_frame sections. If there is information about unused symbols, the implementation is very simple. BTW there is
no need to do full decoding of eh_frame records to remove garbage.</span></span></p>
<p class="MsoNormal"><span><span style="color:#212121">Paul is right there will be code size overhead. Eh_frame is usually created per a compilation module with common information in CFI. Multiple eh_frames will cause a lot of redundant CFI. There
might be a case when the total size of redundant CFIs will be greater than the total size of removed garbage.</span></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span><span style="color:#212121"> </span></span></p>
</div>
<div>
<p class="MsoNormal"><span><span style="color:#212121">As I wrote in the previous message, I don't think there's a size issue in link results because even existing linkers merge CIEs by contents.</span></span><span style="color:#212121"></span></p>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div></div></div>
</div>
<br>______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">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/<wbr>mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>