Hi Taylor,
> 1. How does the lli keep itself from being overwritten by a misbehaving
> program?
It doesn't. If you want that kind of safety you have to generate input
IR that checks all its accesses and avoids unsafe constructs.
> 3. does it support multithreading?
It should be compatible with multithreading. Using current MCJIT, all
compilation happens before execution so you can just write IR that
uses your OS primitives to create and manage your threads. But doing
that management is your responsibility.
(The old JIT and interpreter seem to have some kind of support for a
"llvm_start_multithreaded" function to stop LLVM stomping on its own
structures during execution, but both of those have issues of their
own: you should be using the MCJIT unless you have good reason not to.
If you *do* have good reason, we'd like to hear about it so we can
improve MCJIT).
> 4. does lli allow for multitasking or do you just ran one VM per program?
>
> 5. if it does support multitasking how does it keep processes from
> colliding?
>
> 6. if it does not support multitasking and runs one VM per process then
what
> means are there for communication of processes?
There's no LLVM help for running multiple tasks, you have to rely on
your OS support again.
> 7. does lli support emulated virtual memory?
I'm not exactly sure what you mean, but I suspect the answer is "no,
do it in your IR using OS primitives".
As Dmitri said, LLVM isn't really designed to be a friendly hosted
environment, but a way to compile (and possibly run in the same
process) native code.
Cheers.
Tim.