search for: eh_frame_hdr

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 or two? What do you mean “...

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

...kernel and libs): Linking CXX executable ../../bin/llvm-dis [ 93%] Built target llvm-dis Scanning dependencies of target llc [ 93%] Building CXX object tools/llc/CMakeFiles/llc.dir/llc.cpp.o Linking CXX executable ../../bin/llc /usr/bin/ld: error in ../../lib/./LLVMX86AsmPrinter.o(.eh_frame); no .eh_frame_hdr table will created. /usr/bin/ld: error in ../../lib/./LLVMX86CodeGen.o(.eh_frame); no .eh_frame_hdr table will be created. [ 93%] Built target llc Scanning dependencies of target llvm-ranlib Scanning dependencies of target lli [ 95%] Building CXX object tools/lli/CMakeFiles/lli.dir/lli.cpp.o Linki...

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

...t 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 /home/aph/llvm/Release/lib/LLVMExecutionEngine.o(.eh_frame ); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMJIT.o(.eh_frame); no .eh_fr ame_hdr table will be created. Configured with: ./configure \ --disab...

>Keeping .eh_frame separated should still simplifies the linker because >until the last step of building .eh_frame and .eh_frame_hdr, we don't >really need to parse .eh_frame sections. So, if we have separate .eh_frame >sections on -ffunction-sections, all we have to do is (1) garbage-collect >sections and (2) construct .eh_frame and .eh_frame_hdr sections from live >.eh_frame sections. At step 1, .eh_frame can b...

...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 /home/aph/llvm/Release/lib/LLVMExecutionEngine.o(.eh_frame > ); no .eh_frame_hdr table will be created. > /usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMJIT.o(.eh_frame); no .eh_fr > ame_hdr table will be created. this looks like a b...

...(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) at line 1 /usr/bin/ld: error in /tmp/llvm_QbpfxH/hello.o(.eh_frame); no .eh_frame_hdr table will be created. Failed with unknown error (or has stderr output) at line 1 /usr/bin/ld: error in /tmp/llvm_cxO8Q6/together.o(.eh_fra...

On Wed, Oct 2, 2019 at 8:41 PM Maksim Panchenko via llvm-dev < llvm-dev at lists.llvm.org> wrote: > *Pessimization/overhead for stack unwinding used by system-wide profilers > and > for exception handling* > > Larger CFI programs put an extra burden on unwinding at runtime as more CFI > (and thus native) instructions have to be executed. This will cause more > overhead

...in the function) you have to execute an entirely new set of CFI > instructions > > except for the common CIE part. While indeed this is not as bad, on > average, the overall > > active memory footprint will increase. > > > > Creating one FDE per basic block means that .eh_frame_hdr, an allocatable > section, > > will be bloated too. This will increase the FDE lookup time. I don’t see > .eh_frame_hdr > > being mentioned in the proposal. > > > > Maksim > > > > On 10/2/19, 12:20 PM, "Krzysztof Pszeniczny" <kpszeniczny at goo...

Hi, We're working on adding exception handling support for a downstream bare-metal target. I read through the LLVM exception handling docs [1] and went through some patches from other backends to understand what parts we need to implement. We're now at a point were it feels like it should work, but unfortunately exceptions are still not getting caught. Our target uses DWARF

Hi, I was very curious so I went ahead and resubmitted Pete’s original change. So far no buildbot failures, looks promising. On 26 January 2016 at 09:19, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Sent from my iPhone On Jan 26, 2016, at 7:40 AM, Dave Bozier via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at

...ts" 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: 10848 size..bss: 48 size..comment: 218 size..ctors: 16 size..data: 4 size..dtors: 16 size..dynamic: 416 size..dynsym: 168 size..eh_frame: 172 size..eh_frame_hdr: 44 I can find all these statistics in a file called: /scratch/leone/grosser/base/sandbox/test-2017-07-04_06-14-43/outputTd2xPU.json but they do not appear in: /scratch/leone/grosser/base/sandbox/test-2017-07-04_06-14-43/report.json and in fact do not seem to be submitted to the LNT server....

...t 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 /home/aph/llvm/Release/lib/LLVMExecutionEngine.o(.eh_frame ); no .eh_frame_hdr table will be created. /usr/bin/ld: error in /home/aph/llvm/Release/lib/LLVMJIT.o(.eh_frame); no .eh_fr ame_hdr table will be created. Configured with: ./configure \ --disab...

...t to %obj* store %obj* %myobj, %obj** %ptr ret i32 0 } 22:40|melis at juggle2:~/projects/llvm_gc> llc root.ll 22:40|melis at juggle2:~/projects/llvm_gc> gcc -o r root.s /usr/lib/gcc/i686-pc-linux-gnu/4.3.4/../../../../i686-pc-linux-gnu/bin/ld: error in /tmp/ccGhPZDb.o(.eh_frame); no .eh_frame_hdr table will be created. I'm actually puzzled that exception handling code is generated, and more so that it is caused by the llvm.gcroot call. If I comment that one out all no exception handling stuff is created: 22:42|melis at juggle2:~/projects/llvm_gc> cat root.s .file "root....

...I instructions > >> > >> except for the common CIE part. While indeed this is not as bad, on average, the overall > >> > >> active memory footprint will increase. > >> > >> > >> > >> Creating one FDE per basic block means that .eh_frame_hdr, an allocatable section, > >> > >> will be bloated too. This will increase the FDE lookup time. I don’t see .eh_frame_hdr > >> > >> being mentioned in the proposal. > >> > >> > >> > >> Maksim > >> > >> > &g...

...quot;-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: 10848 size..bss: 48 size..comment: 218 size..ctors: 16 size..data: 4 size..dtors: 16 size..dynamic: 416 size..dynsym: 168 size..eh_frame: 172 size..eh_frame_hdr: 44 I can find all these statistics in a file called: /scratch/leone/grosser/base/sandbox/test-2017-07-04_06-14-43/outputTd2xPU.json but they do not appear in: /scratch/leone/grosser/base/sandbox/test-2017-07-04_06-14-43/report.json and in fact do not seem to be submitted to the LNT server. M...

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 dump. > It would be great if there was a single > parser used by all llvm tools. Absolutely. We'll get to that stage, I hop...

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

...mmon CIE part. While indeed this is not as bad, on average, the overall > > > >> > > > >> active memory footprint will increase. > > > >> > > > >> > > > >> > > > >> Creating one FDE per basic block means that .eh_frame_hdr, an allocatable section, > > > >> > > > >> will be bloated too. This will increase the FDE lookup time. I don’t see .eh_frame_hdr > > > >> > > > >> being mentioned in the proposal. > > > >> > > > >> > >...