similar to: [LLVMdev] LLVM build problem

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

I constructed an LLVM 2.7 VS solution with cmake, but it has 66 projects: ALL_BUILD, ".\ALL_BUILD.vcproj" BrainF, "examples\BrainF\BrainF.vcproj" Fibonacci, "examples\Fibonacci\Fibonacci.vcproj" FileCheck, "utils\FileCheck\FileCheck.vcproj" HowToUseJIT,

One thing that helps me understand complex software is a dependency graph. I found an LLVM dependency graph at https://llvm.org/svn/llvm-project/llvm/tags/RELEASE_16/docs/UsingLibraries.html#dependencies but it's really messy and hard to follow. From that graph I made a cleaner graph by hand (attached)... sorry about the fax-quality scan. But I have some questions about it... -

Erick, I see the problem. The llvm-config linker options are baked into the ocaml library, which is good. But for the execution engine, that link line includes the full paths to some .o files. Those paths come from llvm-config, and they vary before and after installation. (Before install, they point into the source tree as you're seeing.) You could theoretically get working

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

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

>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

We are running kernel 2.6.18-164.6.1.el5 with exporting 3 aoe provided ext4 directories. For a couple of weeks we had a small number of users using the system with no issues, today we added 7 users and the system crashed and did not perform correctly since. Nov 23 10:20:03 sulphur rpc.idmapd[5199]: nfsdcb: id '-2' too big! Nov 23 10:42:25 sulphur nfsd[27306]: nfssvc: Setting version

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've run into a problem with the ocaml bindings and the jit. It builds fine without the jit, but when I try to include it it tries to use the c object files from the build location, instead of the install location: > llvm-config --libdir --libfiles engine /opt/local/lib /opt/local/lib/LLVMX86.o /opt/local/lib/libLLVMSelectionDAG.a /opt/local/lib/libLLVMCodeGen.a

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What is the expected footprint of a tool using the LLVM JIT? I have created a simple project that uses the LLVM C++ API to JIT calls to XPCOM method signature... it works well, but the component DLL is very large (Linux x86-74, 5.8MB optimized and stripped). Is this normal? Am I linking to "too much" or not using the correct link flags?

On Sun, Nov 07, 2004 at 11:40:58PM +0100, Basile STARYNKEVITCH wrote: > I did "make" inside llvm/examples/ and inside > llvm/examples/HowToUseJIT/ and expected to get an ELF executable.. But > I've only got the 2 Release/HowToUseJIT.[do] files.. All executables are placed in tools/$(BUILD_TYPE), in your case, llvm/tools/Release. That is there from the time before we had

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

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

Commit-ID: 048bfb0df170d4a43142adcee8a2dffdfc2c1e9f Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=048bfb0df170d4a43142adcee8a2dffdfc2c1e9f Author: James Cowgill <james.cowgill at mips.com> AuthorDate: Fri, 2 Mar 2018 08:33:01 -0800 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Wed, 2 Jan 2019 03:08:04 +0000 [klibc] mips: use -Ttext-segment