similar to: [RFC] Making .eh_frame more linker-friendly

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

> But if we still need to deal with CIEs and generate .eh_frame_hdr in a special way, > does it make sense to make this change to simplify only a small part of a linker? For huge C++ projects this could improve link time if GC is a bottleneck. It will also improve eh_frame_hdr build time because you don’t spend time on parsing garbage. However a linker will have to have two versions of GC:

>> 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,

Hi Igor, > 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 CIEs, right? Yes, a linker needs some details but not all of them. It needs to know sizes of records and initial locations (PC Begin) to find out which functions FDEs belong to. > So, is there any difference whether it knows that in one place

>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

Hi, 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. 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

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

No I haven't. Thank you for the pointer. Looks like the problem of the inverted edges was discussed there. But I guess my bigger question is this: why do we still create one big .eh_frame even if -ffunction-sections is given? When the option is given, Clang creates .text, .rela.text and .gcc_exception_table sections for each function, but it still creates a monolithic .eh_frame that covers

Checking out LLVM from svn and building, I get: llvm[2]: Linking Release executable ModuleMaker (without symbols) /usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMX86.o(.eh_frame); no .eh_fr ame_hdr table will be created. /usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMInterpreter.o(.eh_frame); n o .eh_frame_hdr table will be created. /usr/bin/ld: error in

Hi Andrew, > Checking out LLVM from svn and building, I get: > > llvm[2]: Linking Release executable ModuleMaker (without symbols) > /usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMX86.o(.eh_frame); no .eh_fr > ame_hdr table will be created. > /usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMInterpreter.o(.eh_frame); n > o .eh_frame_hdr table will be created. >

Hi, Many linkers including lld have a feature to eliminate unused sections from output to make output smaller (which is essentially a mark-sweep gc where sections are vertices and relocations are edges). lld and GNU gold have yet another feature, ICF, to merge functions by contents to save more space. When we remove or merge a function, we want to eliminate its exception handling information as

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

On x86_64-linux (ubuntu 8.04), we now have 3 test fails. This happened as of revision 61765 (see http://google1.osuosl.org:8011/builders/llvm-x86_64-linux/builds/1316). The failure mode is: Failed with unknown error (or has stderr output) at line 1 /usr/bin/ld: error in /tmp/llvm_wwflUD/false.o(.eh_frame); no .eh_frame_hdr table will be created. Failed with unknown error (or has stderr output)

I 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

>@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

Hi, We’d like to propose an extension to both the map file and the print-gc/icf-sections output. This extension would be to report the pieces of .eh_frame and SHF_MERGE sections in these files somehow. Since all (or at least the majority) of the contents of these sections in the output come from inputs, it would be beneficial in trying to associate the output contents with where they came from,

It seems that showing eh_frame section pieces in the map file is useful, but I wonder what would be a concrete use case of the feature. Do you mind if you ask you to describe your plan if you have a use case in mind? On Tue, Feb 6, 2018 at 4:27 AM, James Henderson < jh7370.2008 at my.bristol.ac.uk> wrote: > Hi, > > > > We’d like to propose an extension to both the map file

Dear all, I wanted to gather LLVM statistics with lnt and found a nice flag, but am unsure how such statistics can be made available in the LNT web interface. --cmake-define=TEST_SUITE_COLLECT_STATS=ON which allows me to gather all the LLVM "-stats" output. On top of this I see that the LNT cmake test-suite also dumps code-size statistics when running, that look as follows: size:

Hi all, I'm toying around with LLVM's GC support and am struggling with the following. I have a little test snippet (a .ll file with IR) that uses llvm.gcroot to mark a GC root, but when I compile it to assembly with llc, followed by generating an executable with gcc I get an error related to exception handling: 22:40|melis at juggle2:~/projects/llvm_gc> cat root.ll %obj = type { i8*,

Sent from my iPhone > On Jan 26, 2016, at 7:40 AM, Dave Bozier via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > There is some eh_frame section parsing going on in the linker which is > required for .eh_frame_hdr creation and probably useful for dead-frame > elimination in the future. I think there's 2 linker parsers (a macho one and elf/coff), runtime dyld, and dwarf