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

>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).

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.

>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.
Clarification: not the same, but something close. At least there are multiple
.eh_frame sections in output.

As far I understand what we need for this experiment is for each text section
emit its own .eh_frame and set
SHF_LINK_ORDER and sh_link field for the latter pointing to .text section. Looks
code from patch above
can be adopted to do that.

George.

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>

>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.

I'll start investigating the implementation and try to update/reimplement
and check that all.?

(Can probably take some time because want to investigate llvm/mc code a little
as it is new for me).

>
>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.
Yes and that is my concern. I think we can't just drop supporting
optimization of objects produced not by clang/llvm-mc.
If we drop supporting split section case, we will lose it and need to be sure
that is fine for users of LLD.
That probably the question is if other compilers will want to do the something
same or not.
Anyways that is a bit forward question probably, let me do experiments with it
for start to check the idea.

George.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171121/454437e8/attachment.html>