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. >>>> >>>> >>> >> >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100122/96505c45/attachment.html>
I mean "on program _entry_". Time for bed... 2010/1/22 James Williams <junk at giantblob.com>> 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. >>>>> >>>>> >>>> >>> >>> >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100122/614494c8/attachment.html>
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. >>> >>> >>> >> >> > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100122/7e7a2a19/attachment.html>
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.
>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>