similar to: [LLVMdev] Revision 61765 causes ld to think eh_frame has errors

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

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

>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

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

Hi, While building svn using CMake on an Ubuntu 9.04 system (gcc 4.3.3, binutils 2.19.1, 32-bit 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

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

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

We need to build with -mno-pic to disable all uses of GP, as well as use a custom linker script to avoid collisions between klibc.so's and the executable's segments. Signed-off-by: James Clarke <jrtc27 at jrtc27.com> --- usr/klibc/arch/ia64/MCONFIG | 3 + usr/klibc/arch/ia64/crt0.S | 4 - usr/klibc/arch/ia64/klibc.ld | 267 ++++++++++++++++++++++++++++++++++++++++++

Commit-ID: 8418552770110e9864ab24d60d8481fac58d3a65 Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=8418552770110e9864ab24d60d8481fac58d3a65 Author: James Clarke <jrtc27 at jrtc27.com> AuthorDate: Mon, 21 Jan 2019 21:26:57 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Mon, 21 Jan 2019 22:51:27 +0000 [klibc] ia64: Fix shared build We

On Thu, Mar 20, 2014 at 10:41 AM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > On 19 March 2014 17:31, David Blaikie <dblaikie at gmail.com> wrote: >> While comparing debug info between GCC and Clang I found a section >> that only Clang produces and GCC never produces: debug_frame. >> >> It seems (though I haven't verified this with absolute

Please look at the fragment of the hex dump of LLVM-created ELF showing the beginning and end of .eh_frame: .eh_frame begin 000297a0 14 00 00 00 00 00 00 00 01 7a 52 00 01 78 10 01 |.........zR..x..| 000297b0 1b 0c 07 08 90 01 00 00 18 00 00 00 1c 00 00 00 |................| <...skipped...> 0002cb00 00 00 00 00 0b 01 00 00 00 41 0e 10 86 02 43 0d |.........A....C.| 0002cb10 06 42

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

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

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

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

While comparing debug info between GCC and Clang I found a section that only Clang produces and GCC never produces: debug_frame. It seems (though I haven't verified this with absolute certainty) as though GCC just always uses eh_frame. LLVM on the other hand sometimes uses eh_frame and sometimes uses debug_frame. Here's an example: int f1(); int i = f1(); void func() { } Compiled with

> The problem with this is that __register_frame function (in libgcc_s.so), > registering .eh_frame with an exception handler, only takes the pointer to > .eh_frame, and not the size of data, and should be able to detect the end of > data by scanning it and hitting zero DWORD (size). There is no trailing > zero, and it runs into the next section and tries to interpret it as an >

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