similar to: [LLVMdev] LLVM build problem

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

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

> 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

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

>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

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

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,

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

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

Hello Anton Thu, 3 Aug 2006 15:06:56 +0400 you wrote: > here it is in the attachment :) Ok. Could you also send LibDeps.txt file? It should be in /obj/tools/llvm-config directory -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

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

Hi all, Not so long ago we have found ourselves in need of a robust _eh_frame parser. All we wanted is the ability to parse .eh_frame section emitted by LLVM's MCJIT. Considering this, LLVM would be a natural place for implementing such parser. Previous email thread about the issue (https://groups.google.com/forum/#!topic/llvm-dev/Vb_VYU7Eo0k) showed some interest among the community. Folks

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

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

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:

Nick Lewycky wrote: > 2009/6/30 Andrew Haley <aph at redhat.com <mailto:aph at redhat.com>> > > Nick Lewycky wrote: > > I'm seeing this new build failure, starting some time yesterday on > ARM: > > Yes. It's just a matter of defining __sync_val_compare_and_swap_4: > >

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

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

Hi Tobias, The metrics that you can collect in LNT are fixed per "test suite". There are 2 such "test suite"s defined in LNT at the moment: nts and compile. For more details on this, see http://llvm.org/docs/lnt/concepts.html#test-suites. AFAIK, If you need to collect different metrics, you'll need to define a new "test suite". I'm afraid I don't really