[LLVMdev] Exception handling question

Garrison Venn gvenn.cfe.dev at gmail.com
Tue Feb 2 17:15:34 PST 2010

Hi James,

Just wanted to update you. As you implied the problem here is that
the personality function has to be jitted before the code that contains
the corresponding llvm.eh.selector intrinsic instruction is jitted. I verified
this by creating a generated version of the personality function which unless
I jitted first, gave me the same error when running the code. Since you are using
tools versus the API, and therefore do not have direct control of JIT order, I 
was wondering if there is not another way to create this same outcome without
having to resort to calling the personality function directly before referencing
it in the llvm.eh.selector intrinsic (build order?). Anyway I know from your
posts that you are way beyond this. Have you already solved this issue
without a preliminary call?


On Jan 25, 2010, at 8:09, James Williams wrote:

> 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
> 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


More information about the llvm-dev mailing list