[llvm-dev] [RFC] Making .eh_frame more linker-friendly

[Rui Ueyama via llvm-dev]

On Tue, Nov 21, 2017 at 12:56 AM, George Rimar <grimar at accesssoftek.com>
wrote:

> >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.
> >
> >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.
>
> I tried to investigate how to implement this and suddenly found that Rafael
> looks already tried to to the same in 2015: https://marc.info/?l=llvm-
> commits&m=144683596826489.
>
> Basing on comments, approach worked but had slowdowns for bfd and crashed
> gold (or made it slower too).  I can try to investigate this again and
> either reimplement
> or ressurrect that code to check how multiple .eh_frame sections behave
> nowadays, but few things are unclear for me.
>
> Rafael, you wrote in description that you would not land that patch that
> time, do
> you also think now we should try this again ? (since we have production
> ready LLD now).
>
> (Assuming we want to try this again)
> What are we going to do with possible slowdowns of GNU linkers ? I guess
> some option can be introduced
> to keep old behavior for them, but than also not sure how LLD should
> handle 2 different types of
> inputs (with single/multiple .eh_frame).
>

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.

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.

Any considerations of what should we try/check at first ? (I guess
> perfomance numbers for bfd/gold/LLD
> is major point of interest, size of output, anything else ?).
>
> George.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171121/7431a403/attachment.html>