[LLVMdev] JIT crash takes down host-application
fk.fuchs at googlemail.com
Mon Jul 19 04:20:25 PDT 2010
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.
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
> 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
> 2010/7/18 Nick Lewycky <nicholas at mxc.ca>
>> Frank Fuchs wrote:
>>> I'm doing some tests concerning the embedding of LLVM and clan in my
>>> 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?
>> 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:
>> 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.
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev