[LLVMdev] Exception handling question

Mon Jan 25 05:09:31 PST 2010

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  0x00007ffff6edbf50 in *__GI_abort () at abort.c:92
#2  0x00007ffff6ed1481 in *__GI___assert_fail (
    assertion=0x11acb18 "!isAlreadyCodeGenerating && \"Error:
Recursive compilation detected!\"",
    file=<value optimised out>, line=624,
    function=0x11ad740 "void
llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, const
llvm::MutexGuard&)") at assert.c:81
#3  0x0000000000d3e2c2 in llvm::JIT::runJITOnFunctionUnlocked
(this=0x1781e90, F=0x17196b0, locked=...) at JIT.cpp:624
#4  0x0000000000d3e6a6 in llvm::JIT::getPointerToFunction
(this=0x1781e90, F=0x17196b0) at JIT.cpp:680
#5  0x0000000000d66d32 in llvm::ExecutionEngine::getPointerToGlobal
(this=0x1781e90, GV=0x17196b0) at ExecutionEngine.cpp:473
#6  0x0000000000d618b1 in llvm::JITDwarfEmitter::EmitCommonEHFrame
(this=0x177a3c0, Personality=0x17196b0)
    at JITDwarfEmitter.cpp:522
#7  0x0000000000d5fb6f in llvm::JITDwarfEmitter::EmitDwarfTable
(this=0x177a3c0, F=..., jce=...,
    StartFunction=0x7ffff7f4c090 "H\203\354\bH\270 @\376\367\377\177",
EndFunction=0x7ffff7f4c0b6 "\315\315c\374\037",
    EHFramePtr=@0x7fffffffd8b0) at JITDwarfEmitter.cpp:55
#8  0x0000000000d46599 in finishFunction (this=0x1788380, F=...) at
JITEmitter.cpp:1244
#9  0x0000000000935769 in runOnMachineFunction (this=0x17baf90,
MF=...) at X86CodeEmitter.cpp:137
#10 0x0000000000daac17 in llvm::MachineFunctionPass::runOnFunction
(this=0x17baf90, F=...) at MachineFunctionPass.cpp:27
#11 0x00000000010afdc9 in llvm::FPPassManager::runOnFunction
(this=0x1782370, F=...) at PassManager.cpp:1348
#12 0x00000000010afaa5 in llvm::FunctionPassManagerImpl::run
(this=0x1781fa0, F=...) at PassManager.cpp:1300
#13 0x00000000010af72d in llvm::FunctionPassManager::run
(this=0x17100d0, F=...) at PassManager.cpp:1230
#14 0x0000000000d3e2f2 in llvm::JIT::runJITOnFunctionUnlocked
(this=0x1781e90, F=0x1718320, locked=...) at JIT.cpp:628
#15 0x0000000000d3e6a6 in llvm::JIT::getPointerToFunction
(this=0x1781e90, F=0x1718320) at JIT.cpp:680
#16 0x0000000000d44382 in JITCompilerFn (Stub=0x7ffff7fe401c) at
JITEmitter.cpp:709
#17 0x0000000000b44caa in X86CompilationCallback2
(StackPtr=0x7fffffffdf58, RetAddr=140737354022940) at
X86JITInfo.cpp:365
#18 0x0000000000b44baa in X86CompilationCallback () at X86JITInfo.cpp:40
#19 0x00007ffff7fe401d in ?? ()
#20 0x00007ffff7f4c030 in main ()
#21 0x00007fffffffdf90 in ?? ()
#22 0x0000000000ace204 in llvm::APInt::getZExtValue (this=0x16fbee0)
    at /home/degs/Source/llvm-trunk/llvm/include/llvm/ADT/APInt.h:1046
#23 0x0000000000d66974 in llvm::ExecutionEngine::runFunctionAsMain
(this=0x1781e90, Fn=0x1718900, argv=...,
    envp=0x7fffffffe6c8) at ExecutionEngine.cpp:389
#24 0x00000000009012fc in main (argc=3, argv=0x7fffffffe6a8,
envp=0x7fffffffe6c8) at lli.cpp:216

-- James

On 22/01/2010, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote:
> 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 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.
>> 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.
>>
>> Garrison
>>
>> On Jan 22, 2010, at 12:08, James Williams wrote:
>>>
>>>
>>> 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. In my mind a different
>>> example/different doc. would be needed to explain how
>>> a bit code driven JIT exception mechanism works. Sure the semantics and
>>> syntax of the unwind mechanism would be the
>>> same, but how/where the dwarf is emitted could be different. I do know
>>> that different classes are used to emit dwarf code
>>> for non-JIT projects vs what classes are used in the wiki JIT example. I
>>> know you understand this already,  but I just wanted to
>>> make it clear for the readers of this list.
>>>
>>> In principle though what I'm trying to do ought to work though - I don't
>>> see anything fundamentally different about my bitcode test that lli loads
>>> from a file versus what the wiki JIT exception example generates at
>>> runtime. Both should result in similar IR in memory driving the JIT to
>>> generate the required unwind information from inkove instructions and the
>>> llvm.eh intrinsics - there's no other magic going on in the JIT example
>>> (is there?)
>>>
>>> Anyway, I now have LLVM trunk from svn compiled with debug information,
>>> which makes it easier to see what's going on. Assuming I get to the
>>> bottom of it I'll post an update here.
>>>
>>> -- James
>>>
>>> Garrison
>>>
>>> PS: I would find if extremely useful, if you would post your results once
>>> you've figured out the issues.
>>>
>>>
>>> On Jan 22, 2010, at 10:31, James Williams wrote:
>>>
>>>>
>>>>
>>>> 2010/1/22 James Williams <junk at giantblob.com>
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>