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

[Evgeny Astigeevich via llvm-dev]

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/0e535a3a/attachment.html>