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 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&): Assertion `!isAlreadyCodeGenerating && "Error: Recursive compilation detected!"' failed. ... 6 lli 0x0000000000d3f5e2 llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) + 62 7 lli 0x0000000000d3f9c6 llvm::JIT::getPointerToFunction(llvm::Function*) + 686 8 lli 0x0000000000d67c86 llvm::ExecutionEngine::getPointerToGlobal(llvm::GlobalValue const*) + 70 9 lli 0x0000000000d62805 llvm::JITDwarfEmitter::EmitCommonEHFrame(llvm::Function const*) const + 613 10 lli 0x0000000000d60ac3 llvm::JITDwarfEmitter::EmitDwarfTable(llvm::MachineFunction&, llvm::JITCodeEmitter&, unsigned char*, unsigned char*, unsigned char*&) + 335 ... Ciao, Duncan.
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 running llvm-ld without -native 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&): Assertion `!isAlreadyCodeGenerating && "Error: Recursive > compilation detected!"' failed. > ... > 6 lli 0x0000000000d3f5e2 > llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard > const&) + 62 > 7 lli 0x0000000000d3f9c6 > llvm::JIT::getPointerToFunction(llvm::Function*) + 686 > 8 lli 0x0000000000d67c86 > llvm::ExecutionEngine::getPointerToGlobal(llvm::GlobalValue const*) + 70 > 9 lli 0x0000000000d62805 > llvm::JITDwarfEmitter::EmitCommonEHFrame(llvm::Function const*) const + 613 > 10 lli 0x0000000000d60ac3 > llvm::JITDwarfEmitter::EmitDwarfTable(llvm::MachineFunction&, > llvm::JITCodeEmitter&, unsigned char*, unsigned char*, unsigned char*&) + > 335 > ... >Thanks for looking at this. Yes, I realise this will link to bitcode and that the result is a script that runs lli. I kind of just expected JIT to work, particularly since the example code on the wiki uses JIT. The JIT is what my project will eventually target (goal is an out of process compiler will incrementally generate bitcode on disk combined with an application server that will run resulting bitcode via JIT) and hence I've only been testing on the JIT. I'll see if I can work around the recursive compilation problem. -- James> Ciao, > > Duncan. > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100122/05532e6a/attachment.html>
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 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 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&): Assertion `!isAlreadyCodeGenerating && "Error: Recursive >> compilation detected!"' failed. >> ... >> 6 lli 0x0000000000d3f5e2 >> llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard >> const&) + 62 >> 7 lli 0x0000000000d3f9c6 >> llvm::JIT::getPointerToFunction(llvm::Function*) + 686 >> 8 lli 0x0000000000d67c86 >> llvm::ExecutionEngine::getPointerToGlobal(llvm::GlobalValue const*) + 70 >> 9 lli 0x0000000000d62805 >> llvm::JITDwarfEmitter::EmitCommonEHFrame(llvm::Function const*) const + 613 >> 10 lli 0x0000000000d60ac3 >> llvm::JITDwarfEmitter::EmitDwarfTable(llvm::MachineFunction&, >> llvm::JITCodeEmitter&, unsigned char*, unsigned char*, unsigned char*&) + >> 335 >> ... >> > Thanks for looking at this. > > Yes, I realise this will link to bitcode and that the result is a script > that runs lli. I kind of just expected JIT to work, particularly since the > example code on the wiki uses JIT. > > The JIT is what my project will eventually target (goal is an out of > process compiler will incrementally generate bitcode on disk combined with > an application server that will run resulting bitcode via JIT) and hence > I've only been testing on the JIT. > > I'll see if I can work around the recursive compilation problem. > > -- James >Sorry - t's only just sunk in that the JIT must use a completely different mechanism to load the eh tables versus having as + ld and the ELF loader do it and that posting the assembler when I was seeing the JIT fail was probably unhelpful. I apologise for the confusion. -- James> > >> Ciao, >> >> Duncan. >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100122/d5700562/attachment.html>