[LLVMdev] a life-cycle question for MCJIT

[Lang Hames]

I can think of a few ways to tackle this.

(1) As you suggested, add a "remove loaded objects" method to MCJIT. I
think this would be straightforward, but haven't thought about it carefully
yet.

(2) Replicate some of MCJIT's functionality so that you can invalidate
before running step one. E.g: You could call libCodeGen to produce an
object file yourself, then scan it using libObject to perform your
validation, then add the validated object to MCJIT using addObjectFile. The
practicality of this option will depend on how much of MCJIT's logic you
need to reimplement to do your validation. If you need to validate memory
layout it'll be prohibitive, but if you just want to scan for prohibited
instructions or calls it may be doable.

(3) Use multiple MCJIT instances chained together by a shared symbol
resolver. This way you could just delete your newly added MCJIT instance if
the IR doesn't validate.

(4) Use Orc. A basic Orc stack looks a lot like MCJIT from outside, but
under the hood it manages multiple RuntimeDyld instances, and allows you to
remove them whenever you like. This is basically option (3) made easy.

- Lang.




On Fri, Jun 5, 2015 at 12:19 AM, David Chisnall <David.Chisnall at cl.cam.ac.uk
> wrote:

> On 5 Jun 2015, at 00:15, Sanjoy Das <sanjoy at playingwithpointers.com>
> wrote:
> >
> > After running step (1) we may, in rare cases, decide that the
> > generated code is not usable by our runtime [*]
>
> This use case is probably also relevant to the PNaCl people - if the
> output of the JIT violates the SFI requirements of their sandboxing
> platform (possible due to a compiler bug) then they need to be able to
> abort.  I think that they’re currently not lazily JITing, but given how
> important startup times are to them this is probably not ideal.
>
> David
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150605/51b30a2f/attachment.html>