[LLVMdev] Exception handling question

[James Williams]

On 3 February 2010 01:15, Garrison Venn <gvenn.cfe.dev at gmail.com> wrote:

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

Hi Garrison,

No, I'm afraid I'm just marking the relevant functions in my runtime library
as 'noinline' and then my runtime calls them on startup to ensure they're
JIT'ed before any exceptions can be thrown.

I don't understand the internals of the LLVM JIT and DWARF exception
handling well enough to known what the correct fix is but I'm concerned that
what I'm doing is a band-aid only - I haven't seen this yet but I'm kind of
expecting to encounter the recursive compilation issue again if some
variable of the build and/or startup sequence causes other non-JIT'ed
functions to be called during DWARF unwind process. This stuff is all a bit
over my head though - last time I implemented exception handling I wrote my
own stuff to avoid having to get to grips with DWARF + unwind...

Thanks again for your help and for the exception handling example by the way
- it's been very useful.
-- James Williams

>
> 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
> >
> >
> [snip]
> >
> > 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
> >>
>
> [snip]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100203/43927d53/attachment.html>