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

>> With GNU gold (GNU Binutils 2.29.51.20171006) 1.14 have an assert:
>> ~/LLVM/Release/bin/clang++ test.cpp -ffunction-sections -o test.o
>> /usr/local/bin/ld: internal error in layout_eh_frame_section, at
>> .././../gold/object.cc:1309
>> It is that place:
>> https://github.com/gittup/binutils/blob/gittup/gold/object.cc#L1372
>> Did not investigate it, but it looks it is place
>> (https://sourceware.org/ml/binutils/2009-06/msg00097.html)
>> mentioned in comment for
>> https://marc.info/?l=llvm-commits&m=144683596826489.
>
>I've committed a patch in gold that should fix this problem:
>
>   https://sourceware.org/ml/binutils/2017-11/msg00541.html
>
>Can you try gold again with this patch applied? You should at least
>get a little further.
>
>If it still doesn't work, could I trouble you for a sample object file?
>
>-cary
I'll try it soon and return with results, thanks !

Just a small clarification: your commit message saying that "LLVM is
experimenting with placing
.eh_frame sections in the COMDAT group", that is true for original
experiment which faced this gold issue
 (https://marc.info/?l=llvm-commits&m=144683596826489), current approach I
am experimented
with (https://reviews.llvm.org/D40352) sets sh_link of .eh_frame to
corresponding .text section instead.
Though anyways issue looks to be that gold did not like to have multiple
.eh_frame sections and that
is what both approaches faced with and your patch seeems fixes that.

George.

>>> With GNU gold (GNU Binutils 2.29.51.20171006) 1.14 have an assert:
>>> ~/LLVM/Release/bin/clang++ test.cpp -ffunction-sections -o test.o
>>> /usr/local/bin/ld: internal error in layout_eh_frame_section, at
>>> .././../gold/object.cc:1309
>>> It is that place:
>>> https://github.com/gittup/binutils/blob/gittup/gold/object.cc#L1372
>>> Did not investigate it, but it looks it is place
>>> (https://sourceware.org/ml/binutils/2009-06/msg00097.html)
>>> mentioned in comment for
>>> https://marc.info/?l=llvm-commits&m=144683596826489.
>>
>>I've committed a patch in gold that should fix this problem:
>>
>>   https://sourceware.org/ml/binutils/2017-11/msg00541.html
>>
>>Can you try gold again with this patch applied? You should at least
>>get a little further.
>>
>>If it still doesn't work, could I trouble you for a sample object
file?
>>
>>-cary
>
>I'll try it soon and return with results, thanks !
I can confirm your patch fixes gold behavior.

I built latest binutils and performed benchmark tests again today.
Following versions of linkers were used:
* GNU ld (GNU Binutils) 2.29.51.20171129
* GNU gold (GNU Binutils 2.29.51.20171129) 1.14
* LLD 6.0.0 (trunk 319302) (compatible with GNU linkers)

--no-threads was set for gold and LLD tests.

Clang link time with single .eh_frame section in objects.
* ld.bfd:  2,940055212 seconds time elapsed  ( +-  0,17% ) (t1)
* ld.gold: 0,994370076 seconds time elapsed  ( +-  0,11% ) (t2)
* LLD:     0,445566042 seconds time elapsed  ( +-  0,32% ) (t3)

Clang link time with multiple .eh_frame sections in objects.
(latest diff 3 of https://reviews.llvm.org/D40352 applied to produce them).
* ld.bfd:  3,792698701 seconds time elapsed  ( +-  0,19% ) (1,29*t1)
* ld.gold: 1,135187654 seconds time elapsed  ( +-  0,10% ) (1,1416*t2)
* LLD:     0,506076638 seconds time elapsed  ( +-  0,31% ) (1,1358*t3)

George.

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>