[LLVMdev] Exception handling question

[James Williams]

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>