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

[Igor Kudrin via llvm-dev]

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/20171109/696ee3d3/attachment.html>