<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Nov 21, 2017 at 12:56 AM, George Rimar <span dir="ltr"><<a href="mailto:grimar@accesssoftek.com" target="_blank">grimar@accesssoftek.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">>Keeping .eh_frame separated should still simplifies the linker because<br>
>until the last step of building .eh_frame and .eh_frame_hdr, we don't<br>
>really need to parse .eh_frame sections. So, if we have separate .eh_frame<br>
>sections on -ffunction-sections, all we have to do is (1) garbage-collect<br>
>sections and (2) construct .eh_frame and .eh_frame_hdr sections from live<br>
>.eh_frame sections. At step 1, .eh_frame can be handled as a blob of data.<br>
>That is much simpler than (1) parsing all .eh_frame sections beforehand,<br>
>(2) garbage-collect .eh_frame shards, and (3) re-construct .eh_frame and<br>
>.eh_frame_hdr from .eh_frame shards.<br>
><br>
>In addition to that, keeping .eh_frame separated should greatly simplifies<br>
>the logic of identical code folding when comparing not only function<br>
>contents but exception handler information.<br>
<br>
</span>I tried to investigate how to implement this and suddenly found that Rafael<br>
looks already tried to to the same in 2015: <a href="https://marc.info/?l=llvm-commits&m=144683596826489" rel="noreferrer" target="_blank">https://marc.info/?l=llvm-<wbr>commits&m=144683596826489</a>.<br>
<br>
Basing on comments, approach worked but had slowdowns for bfd and crashed<br>
gold (or made it slower too).  I can try to investigate this again and either reimplement<br>
or ressurrect that code to check how multiple .eh_frame sections behave<br>
nowadays, but few things are unclear for me.<br>
<br>
Rafael, you wrote in description that you would not land that patch that time, do<br>
you also think now we should try this again ? (since we have production ready LLD now).<br>
<br>
(Assuming we want to try this again)<br>
What are we going to do with possible slowdowns of GNU linkers ? I guess some option can be introduced<br>
to keep old behavior for them, but than also not sure how LLD should handle 2 different types of<br>
inputs (with single/multiple .eh_frame).<br></blockquote><div><br></div><div>Thank you for taking a look. I think that the answer depends on how much slower GNU linkers are with separate .eh_frame sections. If it is not too slow, it may make sense to generate split .eh_frame sections unconditionally. Otherwise, we might want to add a new option so that clang doesn't produce split .eh_frame sections by default.</div><div><br></div><div>Either way, my aim is to make lld handle only split .eh_frame sections to do gc-sections or ICF. Supporting both non-split and split section doesn't simplify it at all and therefore doesn't make sense. It'd rather increase the work we need to do.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Any considerations of what should we try/check at first ? (I guess perfomance numbers for bfd/gold/LLD<br>
is major point of interest, size of output, anything else ?).<br>
<span class="HOEnZb"><font color="#888888"><br>
George.<br>
</font></span></blockquote></div><br></div></div>