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

>Thank you for taking a look. I think that the answer depends on how much
slower GNU linkers are with separate .eh_frame sections. If it is not too slow,
it may make >sense to generate split .eh_frame sections unconditionally.
Otherwise, we might want to add a new option so that clang doesn't produce
split .eh_frame sections by >default.

I'll start investigating the implementation and try to update/reimplement
and check that all.?

(Can probably take some time because want to investigate llvm/mc code a little
as it is new for me).

>
>Either way, my aim is to make lld handle only split .eh_frame sections to do
gc-sections or ICF. Supporting both non-split and split section doesn't
simplify it at all and >therefore doesn't make sense. It'd rather
increase the work we need to do.
Yes and that is my concern. I think we can't just drop supporting
optimization of objects produced not by clang/llvm-mc.
If we drop supporting split section case, we will lose it and need to be sure
that is fine for users of LLD.
That probably the question is if other compilers will want to do the something
same or not.
Anyways that is a bit forward question probably, let me do experiments with it
for start to check the idea.

George.

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171121/454437e8/attachment.html>

Just finished lib/MC patch ?that creates .eh_frame section for each text
sections,

sets SHF_LINK_ORDER flag and proper sh_link field.


Patch based on Rafael's code mentioned earlier in this thread, uploaded it
just

in case anyone is interested to look at current version,

it is here: https://reviews.llvm.org/D40352.


Now going to start testing of how it works with GNU and LLD linkers.


George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171122/ba4e69f8/attachment.html>

I performed tests basing on first diff of https://reviews.llvm.org/D40352.
(Creates .eh_frame for each .text.*, sets SHF_LINK_ORDER and .sh_link of created
.eh_frame section to point to corresponding .text.)

With use of GNU ld (GNU Binutils) 2.29.51.20171006 it reports errors when
linking sample apps:
~/LLVM/Release/bin/clang++ test.cpp -ffunction-sections -o test.o
/usr/local/bin/ld: .eh_frame has both ordered [`.eh_frame' in
/tmp/test-dbc52e.o] and unordered
                   [`.eh_frame' in
/usr/lib/gcc/x86_64-linux-gnu/5.4.1/../../../x86_64-linux-gnu/crt1.o] sections
/usr/local/bin/ld: final link failed: Bad value

Looks it's code explicitly restricts mixing sections with link order flag
and without:
https://github.com/gittup/binutils/blob/gittup/bfd/elflink.c#L9991

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.

LLD ~head fails here
https://github.com/llvm-mirror/lld/blob/master/ELF/InputFiles.cpp#L392 as
we are trying to do cast to InputSection, though .eh_frame is not regular
InputSection but EhInputSection.

Basing on all above I supposed it should be fine to not emit SHF_LINK_ORDER
flags for start.
I changed implementation so that it emits multiple .eh_frames and sets sh_link
field for
SHT_X86_64_UNWIND sections, but don't set the SHF_LINK_ORDER flag. In that
way only
x64 target is affected and SHT_X86_64_UNWIND sections are known to be .eh_frame
so can be
handled on linker side not by name, what is also nice for start it seems.
(Uploaded current version as diff 2 here: https://reviews.llvm.org/D40352)

With such change LLD and bfd links fine, and I was able to test clang link time.
Clang does not
use exceptions, but x64 ABI still requires .eh_frame sections for functions, and
result objects
contains many of them so I think it is reasonable test. What I did: built clang
with and without
patch, used result compiler binaries for producing 2 sets of release clang
objects
(flags were -fPIC -std=c++11 -ffunction-sections -fdata-sections), used them for
testing link time
with use of ld.bfd and LLD.

Results (30 runs for each):
1) ld.bfd link time before patch: 2,922310802 seconds time elapsed ( +-  0,13% )
   Size: 80 667 832 bytes
2) ld.bfd link time after patch: 3,773565826 seconds time elapsed ( +-  0,13% )
   Size: 80 667 832 bytes
3) LLD link time before patch: 0,419247946 seconds time elapsed ( +-  0,48% )
   Size: 80 738 240 bytes
4) LLD link time after patch: 0,460139012 seconds time elapsed ( +-  0,44% )
   Size: 80 738 240 bytes

There is no difference in size (that is probably expected as linkers do
deduplication optimization, so looks right for me),
slowdown for bfd is about 29%, for LLD about 9.7%.

What we gonna do next ? My plan is to prepare demo patch for LLD to stop parsing
.eh_frames
for GC step and benchmark the results with use of -gc-sections. It also can show
amount of LLD
code reduction/simplification we can have.


George.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171123/84fc462e/attachment.html>