[LLVMdev] Exception handling question

[Garrison Venn]

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>