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

[Reid Kleckner via llvm-dev]

Have you seen the discussion of SHF_LINK_ORDER on the generic-abi@ mailing
list? I think it implements exactly what you describe. My understanding is
that ARM EHABI leverages this for the same purpose.

https://groups.google.com/forum/#!topic/generic-abi/_CbBM6T6WeM

On Wed, Oct 25, 2017 at 6:42 PM, Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
> Many linkers including lld have a feature to eliminate unused sections
> from output to make output smaller (which is essentially a mark-sweep gc
> where sections are vertices and relocations are edges). lld and GNU gold
> have yet another feature, ICF, to merge functions by contents to save more
> space.
>
> When we remove or merge a function, we want to eliminate its exception
> handling information as well. But that isn't very easy to do due to the
> format of .eh_frame. Here are reasons:
>
> 1. Linkers have to parse, split, eliminate exception handling information
> for dead functions, and then reconstruct an .eh_frame section. It is
> tedious, and it doesn't feel very much like a task that linkers have to do
> (linkers usually handle sections as opaque blobs and are agnostic of
> section contents.) That is contrary to other data where section is the
> atomic unit of inclusion/elimination.
>
> 2. From the viewpoint of gc, .eh_frame has reverse edges to sections.
> Usually, if section A depends on section B, there's a relocation in A
> pointing to B. But that isn't the case for .eh_frame, but opposite. If
> section A has exception handling information in .eh_frame section B, B has
> a relocation against A. This makes implementing a gc tricky, and when it is
> combined to (1), it is more tricky.
>
> 3. Comparing .eh_frame contents for equivalence is hard. In order to merge
> functions by contents, we need to verify that their exception handling
> information is also the same, but doing it isn't easy given the current
> .eh_frame format.
>
> So, I don't feel .eh_frame needed to be designed that way. Maybe we can
> improve. Here is my rough idea:
>
> 1. We can emit an .eh_frame section for each .text section. So, if you
> pass -ffunction-sections, the resulting object file would have multiple
> .eh_frame sections. This makes .eh_frame a unit of garbage collection and
> eliminates the need to parse .eh_frame contents. It also makes it very easy
> to compare .eh_frame sections for function merging.
>
> 2. Make each .eh_frame section have a link to its .text section. We could
> set a section index of a .text section to its corresponding .eh_frame's
> sh_link field. This would make gc much easier. (If text section A is
> pointed by an .eh_frame section B via sh_link, that A is alive means B is
> alive. It is still reverse, but this is much more manageable.)
>
> I think doing the above things doesn't break the compatibility with
> existing linkers, and new linkers can take advantage of the format that is
> more friendly to the linker. I don't think of any obvious disadvantage of
> doing them, except that we would have more sections, but I may be wrong as
> I'm no expert of .eh_frame.
>
> What do you guys think?
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171026/bda2b023/attachment.html>