[Mono-list] Running Mono on platforms that can't generate code at runtime.

[Jonathan Pryor]

On Tue, 2005-09-27 at 15:21 -0700, Bruce Wilkie wrote:
> Is anyone doing this / has done this?  Specifically,
> on systems that can't alloc memory that can later be
> executed.

No.  See also:

	http://lists.ximian.com/pipermail/mono-devel-list/2005-February/010432.html
	http://bugzilla.ximian.com/show_bug.cgi?id=61710

It may not even be possible.

There are two primary problems:

(1) The current closest way to getting all executable code on disk is
Ahead of Time compilation (`mono --aot`).  This *still* requires
modifications to the on-disk code to update the memory addresses of
various functions, which requires access to writable + executable
memory.  Game over.

(2)The way the JIT normally works is one method at a time.  A method is
JITed, and any methods it in turn calls refer to JIT stubs.  When the
JIT stub is invoked the JIT is invoked, JITing the referred to method,
and then back-patching the call site to skip the JIT the next time the
original method is invoke.  Repeat ad infinitum.

This not only requires writable+executable memory for the JIT code, but
also for wherever mono patches up existing call sites.

This also impacts the first proposal listed above (the Feb 2005 email to
mono-devel-list).  It proposed JITing methods to 3 levels in depth to
disk and them loading mmaping the disk file.  You *still* need to
back-patch method calls though -- if you don't, you need to JIT the
WHOLE PROGRAM before you start executing, and forget about loading up
code at runtime via Reflection/System.Assembly.Load/etc.

In short, for a decent, well performing, *sane* JIT, it is likely
impossible to get mono to work on a PaX-like system.  If you're willing
to lose most of the capabilities that a JIT affords, then you might be
able to make it work.  No one has expressed much interest to date.

 - Jon