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

If this information is useful, please help other people find it:
Share via:

Evgeny Astigeevich via llvm-dev

2017-Nov-10 13:27 UTC

[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<mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171110/72be530e/attachment-0001.html>

Igor Kudrin via llvm-dev

2017-Nov-10 14:23 UTC

head link

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

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<mailto: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171110/cecf19d9/attachment.html>

Rui Ueyama via llvm-dev

2017-Nov-14 08:51 UTC

head link

[llvm-dev] [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.

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>

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

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

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

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