similar to: [LLVMdev] -enable-eh not default in lli

Hi James, > lli --help says: > > "-enable-eh - Emit DWARF exception handling (default if target supports)" > > But in fact the default on x86-64 linux seems to be disabled, even > though exception handling is supported both for lli and when I use the > JIT as a library. Is this a bug? I can't find where > llvm::DwarfExceptionHandling is being conditionally

Yes. The issue here, as you pointed out, is that your personality function is not called at all. Even if you did nothing in the personality function, associated with the setup caused by llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be called. Your results are acting like either dwarf exception header info is not emitted (llvm::DwarfExceptionHandling = true; not executed

After re-cmaking and rebuilding everything from scratch, I'm seeing failures in MCJIT. It this something known or expected? I build LLVM/clang with pre-packaged clang-3.7.0, with "-stdlib=libc++". Example failure: /w/bld/org/./bin/lli -remote-mcjit -mcjit-remote-process=/w/bld/org/./bin/lli-child-target /w/src/llvm.org/test/ExecutionEngine/MCJIT/remote/eh.ll -- Exit Code:

Hi Lang, I am on Ubuntu 14.04. I am building ToT: llvm, clang, polly, lld, compiler-rt, libcxx, libcxxabi. The build compiler is: clang+llvm-3.7.0-x86_64-linux-gnu-ubuntu-14.04 The failures show up during "make check-all". My cmake command was: cmake -G 'Unix Makefiles' -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=/w/c/org -DLLVM_TARGETS_TO_BUILD:STRING=all

2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > Yes. The issue here, as you pointed out, is that your personality function > is not called at all. > Even if you did nothing in the personality function, associated with the > setup caused by > llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be > called. > Your results are acting like either

2010/1/22 James Williams <junk at giantblob.com> > > > 2010/1/22 Duncan Sands <baldrick at free.fr> > >> Hi James, >> >> >> want to send us your testcase code? Then we can give it a whirl. >>> >>> >>> Test code is at http://giantblob.com/ehtest.tar.gz >>> >>> Thanks for the help. I apologize in

Hi James, Note that the wiki example is a manual JIT example that works directly with the C++ APIs. As you know, no LLVM tools are used, just LLVM libraries. I say this to point out, that in the example, the exception mechanism is under the complete control of the developer moded by the LLVM libraries. In my mind a different example/different doc. would be needed to explain how a bit code

2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > Hi James, > > Note that the wiki example is a manual JIT example that works directly with > the C++ APIs. As you know, no LLVM tools are used, > just LLVM libraries. I say this to point out, that in the example, the > exception mechanism is under the complete control of the > developer moded by the LLVM libraries.

I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed before any unwind happens. -- James 2010/1/22 Garrison Venn <gvenn.cfe.dev at gmail.com> > No, there is no magic. :-) > > To me though, the tools are magic, because I have no clue what they are > doing without looking at them and using them. >

Hi James, > want to send us your testcase code? Then we can give it a whirl. > > > Test code is at http://giantblob.com/ehtest.tar.gz > > Thanks for the help. I apologize in advance if it turns out I'm doing > something stupid! I hope you realise that by running llvm-ld without -native you are actually executing your program from the JIT. I did a native

2010/1/22 Duncan Sands <baldrick at free.fr> > Hi James, > > > want to send us your testcase code? Then we can give it a whirl. >> >> >> Test code is at http://giantblob.com/ehtest.tar.gz >> >> Thanks for the help. I apologize in advance if it turns out I'm doing >> something stupid! >> > > I hope you realise that by

No, there is no magic. :-) To me though, the tools are magic, because I have no clue what they are doing without looking at them and using them. As their function is not germane to my current endeavors, I hope to learn about them from this list, and most likely from your postings. I know it is a common approach, but to me I think bitcode generation to JIT runtime is a a cool feature of LLVM.

Interesting. Was this the reason you were getting the recursive compilation error in JIT::runJITOnFunctionUnlocked(...) (isAlreadyCodeGenerating)? Do you have the time to try your test with 2.7? Garrison On Jan 22, 2010, at 17:37, James Williams wrote: > I've worked around this issue in my test case by simply calling my personality function on program to ensure it's JIT'ed

2010/1/22 Duncan Sands <baldrick at free.fr> > Hi Garrison, > > > %7 = invoke i8* (...)* bitcast (i32 (%struct._Unwind_Exception*)* >> @_Unwind_RaiseException to i8* (...)*)(i64* %6) >> to label %8 unwind label %.finally_pad ; <i8*> [#uses=0] >> >> I am not sure this is going to work, at least from the way I've played >> with

Hi All, I have a program that uses C++ STL a lot. To have the source code for STL functions, I undefined "_GLIBCXX_EXTERN_TEMPLATE" in c++config.h. In spite of this, after compilation (via clang) and linking (via llvm-ld), the resulting bitcode contains a few declared functions (with no definitions). My question is: In the scenario where some function definitions are missing in a llvm

Hi Chris, It did compile when I gave that option. But it gives me an error when I try to run the executable on an Intel machine. ----- 1513158 is not prime. Exception handler needed, but not enabled. Recompile program with -enable-correct-eh-support. lli[0x8429bb4] lli[0x8429dc0] /lib/libc.so.6[0x40128c18] /lib/libc.so.6(abort+0x161)[0x40129cb5] [0x403da922] ../../../i386: line 4: 27606

Is there a problem using 'unwind' with lli? When I run the following program with lli, I get a crash: define i32 @main() { entry: invoke void @throw_something() to label %nounwind unwind label %catch nounwind: ret i32 1 catch: ret i32 0 } define void @throw_something() noreturn { entry: unwind } To run this, I am doing:

Thanks Duncan and Ashok, As Duncan described, "lli -load=libstdc++.dylib ..." works. I, however, encounted an "Illegal instruction" message, while I was trying to interpret a large program. So, does lli have a debug switch for dumping out the details for errors? Using llc is not that simple, and I have not gotten through the compilation process. For instance, "llc -o

On 6 March 2014 18:09, Mark Seaborn <mseaborn at chromium.org> wrote: > LowerAtomic "lowers atomic intrinsics to non-atomic form for use in a > known non-preemptible environment". LowerInvoke strips out exception > handling by converting invokes to calls, so that landingpads, resumes, etc. > become dead and can be removed by a later pass. > > (As an aside,

Vinay, On Thu, Apr 01, 2004 at 02:27:53PM -0500, Vinay S. Belgaumkar wrote: > It did compile when I gave that option. But it gives me an error > when I try to run the executable on an Intel machine. > ----- > 1513158 is not prime. > Exception handler needed, but not enabled. Recompile program with > -enable-correct-eh-support. [snip] This error message is from LLVM, not the