[LLVMdev] JIT crash takes down host-application

[Frank Fuchs]

Is there a way to intercept the calls to abort() or exit(), specifically ?
Disabling all external symbol resolution seems not really feasable since I
need some std libs.

-Frank

2010/7/19 Garrison Venn <gvenn.cfe.dev at gmail.com>

> You could use shared memory or the equivalent of UNIX domain sockets. On a
> UNIX system, you will also probably want to catch
> SIGCHLD along with implementing "nowait" handling behavior in the parent.
> This is of course a low level approach. Higher level
> libraries that you may be using, or other OSs may provide their own
> wrappers.
>
> Garrison
>
> On Jul 19, 2010, at 4:05, Frank Fuchs wrote:
>
> Ok, thank you for your explanation. Is it possible for forked processes to
> share data? Especially for the child process to send some data to the
> parent?
>
> -Frank
>
> 2010/7/18 Nick Lewycky <nicholas at mxc.ca>
>
>> Frank Fuchs wrote:
>>
>>> Hi,
>>>
>>> I'm doing some tests concerning the embedding of LLVM and clan in my
>>> application.
>>> Now I stumbled across the following ... which disturbs me. If the jitted
>>> program crashes,
>>> like e.g. if it contains an assert(0==1) or calls an external function
>>> which cannot be resolved,
>>> the hosting app goes down as well. There seems no error catch.
>>>
>>> Can this anyhow be circumvented?
>>>
>>
>> Fork?
>>
>> LLVM JIT is not a secure VM like Java. Programs running under the JIT are
>> free to make any memory operation or function call that the enclosing
>> program could, even _exit(). You can try to restrict function calls by
>> removing the name resolution:
>>
>>
>>
>> http://llvm.org/doxygen/classllvm_1_1ExecutionEngine.html#af062585affb7cd16bab9867b706ea460
>>
>> and/or installing your own (see InstallLazyFunctionCreator), but
>> ultimately they're the same process/task from the point of view of the
>> operating system and there's no "llvm security model" or anything like that.
>>
>> If you're very determined, you could create an LLVM IR transformation pass
>> which checks every load/store/call and verifies that it's safe, and if it's
>> not verifiable at compile time makes it call back into your program at
>> runtime to do the check and proceed only if it is.
>>
>> Or if you don't need it to be in the same process, don't put it there and
>> let the OS handle the rest.
>>
>> Nick
>>
>
> _______________________________________________
> 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/20100719/2b3ee1e1/attachment.html>