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? -Frank
Those shouldn't be crashes.
assert(foo) turns into:
if (! foo) {
fprintf(stderr, ...assertmsg...);
abort();
}
abort() exits the program without the usual cleanup. That's not a
crash. If you want an failed assertion to do something else, you can
always define your own assert().
As for calling an external function that can't be resolved, perhaps
there's a return code somewhere you're ignoring?
Best,
Martin
On 7/18/2010 1:44 PM, 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?
>
> -Frank
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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
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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100719/a1ead956/attachment.html>