[llvm-dev] [RFC] Making .eh_frame more linker-friendly
Igor Kudrin via llvm-dev
llvm-dev at lists.llvm.org
Thu Nov 9 03:29:26 PST 2017
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
So, is there any difference whether it knows that in one place or two?
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:
> 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...
More information about the llvm-dev