search for: __l_personality

...e way beyond this. Have you already solved this issue without a preliminary call? Garrison On Jan 25, 2010, at 8:09, James Williams wrote: > I think so. It also fails the same way on LLVM trunk from last week. > The full backtrace is below. It appears that frame #3 is a compilation > of __l_personality() and frame #14 is a compilation of f(). The > compilation of __l_personality appears to have been triggered by the > need to output DWARF information for f(). > > -- James > > [snip] > > On 22/01/2010, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote: >> Int...

I think so. It also fails the same way on LLVM trunk from last week. The full backtrace is below. It appears that frame #3 is a compilation of __l_personality() and frame #14 is a compilation of f(). The compilation of __l_personality appears to have been triggered by the need to output DWARF information for f(). -- James #0 0x00007ffff6ed84b5 in *__GI_raise (sig=<value optimised out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007fff...

...ive you are actually executing your program from the JIT. I did a native compilation as follows: used llvm-link to link all of the bitcode into "total.bc"; ran llc on total.bc, producing "total.s"; did "g++ -o total total.s"; ran ./total. It seems to work: $ ./total __l_personality called$ Of course it is probably supposed to work from the JIT too (I don't know anything about the JIT), but it clearly doesn't: when I tried I got: lli: lib/ExecutionEngine/JIT/JIT.cpp:624: void llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const llvm::MutexGuard&): Asserti...

...gram from the JIT. I did a native compilation as > follows: > used llvm-link to link all of the bitcode into "total.bc"; ran llc on > total.bc, > producing "total.s"; did "g++ -o total total.s"; ran ./total. It seems to > work: > > $ ./total > __l_personality called$ > > Of course it is probably supposed to work from the JIT too (I don't know > anything about the JIT), but it clearly doesn't: when I tried I got: > > lli: lib/ExecutionEngine/JIT/JIT.cpp:624: void > llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const >...

...ve compilation as >> follows: >> used llvm-link to link all of the bitcode into "total.bc"; ran llc on >> total.bc, >> producing "total.s"; did "g++ -o total total.s"; ran ./total. It seems to >> work: >> >> $ ./total >> __l_personality called$ >> >> Of course it is probably supposed to work from the JIT too (I don't know >> anything about the JIT), but it clearly doesn't: when I tried I got: >> >> lli: lib/ExecutionEngine/JIT/JIT.cpp:624: void >> llvm::JIT::runJITOnFunctionUnlocked(llvm...

...uting your program from the JIT. I did a native compilation as follows: > used llvm-link to link all of the bitcode into "total.bc"; ran llc on total.bc, > producing "total.s"; did "g++ -o total total.s"; ran ./total. It seems to work: > > $ ./total > __l_personality called$ > > Of course it is probably supposed to work from the JIT too (I don't know > anything about the JIT), but it clearly doesn't: when I tried I got: > > lli: lib/ExecutionEngine/JIT/JIT.cpp:624: void llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const llvm::Mu...

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 James, > > > Yes - sorry I was unclear. I have pruned everything down to a pretty >> minimal test: >> - LLVM 2.6 compiled from source >> - A slightly modified version of Duncan's example ll assembly posted >> earlier >> - A minimal personality function (just a call to fprintf()) in a separate

...; preds = %.try_body > %9 = call i8* @llvm.eh.exception() ; <i8*> [#uses=2] > store i8* %9, i8** %.ex_value > %10 = call i64 (i8*, i8*, ...)* @llvm.eh.selector.i64(i8* %9, i8* bitcast (i32 (i32, i32, i64, %struct._Unwind_Exception*, %struct._Unwind_Context*)* @__l_personality to i8*)) ; <i64> [#uses=1] I think you'll need a "i8* null" at the end of this @llvm.eh.selector.i64 call. -bw -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100121/22ac72f3/attachment...

...; preds = %.try_body %9 = call i8* @llvm.eh.exception() ; <i8*> [#uses=2] store i8* %9, i8** %.ex_value %10 = call i64 (i8*, i8*, ...)* @llvm.eh.selector.i64(i8* %9, i8* bitcast (i32 (i32, i32, i64, %struct._Unwind_Exception*, %struct._Unwind_Context*)* @__l_personality to i8*)) ; <i64> [#uses=1] %11 = icmp eq i64 %10, 0 ; <i1> [#uses=1] %12 = select i1 %11, i64 0, i64 1 ; <i64> [#uses=1] store i64 %12, i64* %.ex_type br label %.finally_handler .finally_handler: ; preds...

Hi James, > Yes - sorry I was unclear. I have pruned everything down to a pretty > minimal test: > - LLVM 2.6 compiled from source > - A slightly modified version of Duncan's example ll assembly posted earlier > - A minimal personality function (just a call to fprintf()) in a > separate C file compiled with gcc-llvm > - A single C++ function in a third file that simply

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

...ollows: >>> used llvm-link to link all of the bitcode into "total.bc"; ran llc on >>> total.bc, >>> producing "total.s"; did "g++ -o total total.s"; ran ./total. It seems >>> to work: >>> >>> $ ./total >>> __l_personality called$ >>> >>> Of course it is probably supposed to work from the JIT too (I don't know >>> anything about the JIT), but it clearly doesn't: when I tried I got: >>> >>> lli: lib/ExecutionEngine/JIT/JIT.cpp:624: void >>> llvm::JIT::runJI...