[LLVMdev] Proper way to handle JIT codegen exceptions?

[Reid Kleckner]

The best way to reliably isolate software errors without leaking memory is
to give the code it's own address space which you can cleanly throw away
afterwards.  In other words, fork a child process.

---

I'm just being cheeky, I agree it would be nice if there were better error
recovery mechanisms.  The current philosophy is that once you shake out the
bugs in your frontend so you always generate valid IR, LLVM *shouldn't*
generate fatal errors.  A fatal error is just as unexpected as a crash, and
trying to recover from either is just as dicey as the other.

Reid

On Fri, Oct 28, 2011 at 2:00 AM, Gregory Junker <gjunker at dayark.com> wrote:

> I am looking through the source and Support/ErrorHandling.cpp/.h says, in
> so
> many words, "don't throw exceptions from inside an installed fatal error
> handling routine".
>
> So how are people handling errors during JIT? For command-line compilers,
> calling exit() or abort() isn't as big a deal -- the compiler is probably
> going to exit anyway. But say, for instance, the host application is
> Firefox
> -- my guess is that just letting exit() handle the situation isn't the
> solution.
>
> So what is the "proper" way to handle exceptional LLVM conditions ("cannot
> select", for instance)? Yes, I know this is something that needs to be
> brought to the programmer's attention, but having the user's application
> crash out on them isn't the way I expect most actual LLVM-JIT-based
> applications are handling these things...
>
> Thanks
> Greg
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111028/a23c3a0c/attachment.html>