search for: d40352

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 /us...

...performed additional benchmarking today and also profiled this. Previously I tried to link clang. I decided to take something much larger today. So what I did was: took chromium sources and built 2 sets of objects. One of them was built with vanilla clang and one with clang+https://reviews.llvm.org/D40352 patch applied. As a result, the second set of object contained multiple .eh_frames (for each text section), and the first set was just regular set. Link times after 200 runs were: 1) ~2332ms for the regular set. 2) ~2464ms for "D40352" set. The difference is about 6%. Does not look too...

>@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? No, as far I remember I did not profile this. All results I had were about linker timing for linking clang (posted in this thread). I think the

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

>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

...t 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.

...s. * 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.