[LLVMdev] Exception handling question
James Williams
junk at giantblob.com
Fri Jan 22 14:37:08 PST 2010
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>
More information about the llvm-dev
mailing list