(original) (raw)
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.
Sent: Friday, November 10, 2017 8:27 PM
To: Igor Kudrin
Cc: nd; llvm-dev@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
Date: Friday, 10 November 2017 at 12:23
To: Evgeny Astigeevich
Cc: nd , "llvm-dev@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 on behalf of Evgeny Astigeevich via llvm-dev
Sent: Friday, November 10, 2017 6:41 PM
To: Igor Kudrin
Cc: llvm-dev@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
Date: Thursday, 9 November 2017 at 11:29
To: Rui Ueyama , Evgeny Astigeevich
Cc: "llvm-dev@lists.llvm.org" , nd
Subject: Re: \[llvm-dev\] \[RFC\] Making .eh\_frame more linker-friendly
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@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.