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

Tue Nov 14 00:51:32 PST 2017

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.

On Fri, Nov 10, 2017 at 11:23 PM, Igor Kudrin via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> 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.
>
>
> Best Regards,
> Igor Kudrin
> C++ Developer, Access Softek, Inc.
> ------------------------------
> *From:* Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
> *Sent:* Friday, November 10, 2017 8:27 PM
> *To:* Igor Kudrin
> *Cc:* nd; llvm-dev at lists.llvm.org
>
> *Subject:* Re: [llvm-dev] [RFC] Making .eh_frame more linker-friendly
>
>
> > 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?
>
>
>
> 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.
>
>
>
> -Evgeny
>
>
>
> *From: *Igor Kudrin <ikudrin at accesssoftek.com>
> *Date: *Friday, 10 November 2017 at 12:23
> *To: *Evgeny Astigeevich <Evgeny.Astigeevich at arm.com>
> *Cc: *nd <nd at arm.com>, "llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>
> *Subject: *Re: [llvm-dev] [RFC] Making .eh_frame more linker-friendly
>
>
>
> Hi Evgeny,
>
>
>
> > 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.
>
>
> 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.
>
>
>
> > What do you mean “one place or two”?
>
>
>
> 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?
>
>
>
> Best Regards,
>
> Igor Kudrin
>
> C++ Developer, Access Softek, Inc.
> ------------------------------
>
> *From:* llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Evgeny
> Astigeevich via llvm-dev <llvm-dev at lists.llvm.org>
> *Sent:* Friday, November 10, 2017 6:41 PM
> *To:* Igor Kudrin
> *Cc:* llvm-dev at lists.llvm.org; nd
> *Subject:* Re: [llvm-dev] [RFC] Making .eh_frame more linker-friendly
>
>
>
> Hi Igor,
>
>
>
> > 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?
>
>
>
> 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.
>
>
>
> > So, is there any difference whether it knows that in one place or two?
>
>
>
> 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.
>
>
>
> Thanks,
>
> Evgeny Astigeevich
>
>
>
> *From: *Igor Kudrin <ikudrin.dev at gmail.com>
> *Date: *Thursday, 9 November 2017 at 11:29
> *To: *Rui Ueyama <ruiu at google.com>, Evgeny Astigeevich <
> Evgeny.Astigeevich at arm.com>
> *Cc: *"llvm-dev at lists.llvm.org" <llvm-dev at lists.llvm.org>, nd <nd at arm.com>
> *Subject: *Re: [llvm-dev] [RFC] Making .eh_frame more linker-friendly
>
>
>
> 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?
>
> So, is there any difference whether it knows that in one place or two?
>
> Best Regards,
> Igor Kudrin
> C++ Developer, Access Softek, Inc.
>
> On 27-Oct-17 3:43, Rui Ueyama via llvm-dev wrote:
>
> On Thu, Oct 26, 2017 at 1:13 PM, Evgeny Astigeevich <
> Evgeny.Astigeevich at arm.com> wrote:
>
> Hi,
>
>
>
> 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.
>
>
>
> Linkers would combine .eh_frame sections into one .eh_frame, so that's not
> an issue, no?
>
>
>
> 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.
>
> 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.
>
>
>
> 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.
>
>
> _______________________________________________
> 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/20171114/ec8e1627/attachment.html>