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

[bd1976 llvm via llvm-dev]

I am very interested in reviving this.



Did anyone get any further with these ideas?



@Grimar: Did you do any profiling of the code? Were the slowdowns

you were seeing fundamental (i.e. due to IO) or could a more optimal

implementation reduce the slowdown? Did you do any end to end

timings for compilation + link time?



The same issues arise for all metadata sections:



.eh_frame

.debug_*

.stack_sizes

etc...



In our proprietary linker we've had to implement special handling

for each of these sections, which we'd love to be able to remove or

reduce.



One fundamental problem is overhead. I posted about

this on the gabi list:



https://groups.google.com/d/msg/generic-abi/A-1rbP8hFCA/EDA7Sf3KBwAJ



Take the .stack_sizes section. There is an llvm bug

which suggests that we should produce multiple .stack_size

sections rather than one monolithic .stack_size section:

https://bugs.llvm.org/show_bug.cgi?id=36717.

However, for .stack_sizes the payload is on average 10 bytes

per function. Splitting into multiple sections on elf x86-64 adds

a overhead of 128 bytes per function. An order of magnitude

increase. However, I don't know of any way to avoid this increase

without adding special case code to the linker?



Another thought is that although the gnu linkers are a concern

upstream, ​on our platform (and others where we are fully in control),

we could use this approach for .eh_frame. We would be able to test

and maintain the separate code paths in the backend.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180328/c55c4bbe/attachment.html>