[LLVMdev] Android JIT patch

[Kaylor, Andrew]

I've got a number of problems with this patch.

First, we have plans to pry apart the remaining strands connecting JIT with MCJIT, so I don't want to do anything that reconnects them.  That is, I'm against moving things from RTDyldMemoryManager into ExecutionEngine.

Second, unless I'm reading it wrong, this relies on static constructors.  That causes headaches and is against the LLVM coding standards.

Third, I don't think sys::DynamicLibrary::AddSymbol() is the right way to go here.  I know I have recently suggested using that function, but I was wrong.  That function exposes symbols to the entire host program as if they were present in a locally loaded shared library.  For some programs that may be acceptable behavior, but it cannot be the default behavior for LLVM.  In particular, MCJIT may not even be generating code for local execution.

The default RTDyldMemoryManager implementation selectively exposes symbols to execution engines for which it is used, and MCJIT/RuntimeDyld clients performing remote execution can (and should) override this behavior.  We probably also need to fix the addGlobalMapping support for MCJIT.

-Andy

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of James Lyon
Sent: Sunday, November 10, 2013 5:45 PM
To: LLVM Dev
Subject: [LLVMdev] Android JIT patch

I've attached a patch which has got JIT compilation working (for me at
least!) on Android. It turns out that the problem was a bunch of intrinsic __aeabi* functions which reside in libgcc.a rather than libc.so so are not available unless explicitly linked in, so it's rather similar to the StatSymbols hack.

I moved the StatSymbols code into ExecutionEngine.cpp rather than JITMemoryManager.cpp since it's required for both the JIT and MCJIT, and deleted the code in RTDyldMemoryManager.cpp which did the same thing for fewer functions. They should now be picked up through the sys::DynamicLibrary::AddSymbol mechanism in both cases. The symbols required for ARM/Android are then added by an identical hack just below.

There's one other minor change since setLastModificationAndAccessTime can't be supported on Android; all relevant system calls are missing from the C library. I've therefore changed the code to fail at runtime rather than compile-time here.

James