[LLVMdev] mmap and vm_protect on ARM+Apple systems

Jim Grosbach grosbach at apple.com
Fri Nov 16 15:58:35 PST 2012


Hi Andy,

On Nov 16, 2012, at 1:56 PM, "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote:

> Hi,
>  
> Can anyone tell me something about mmap and vm_protect on ARM+Apple systems?

Some. :)

>  
> I’m working on a new memory manager implementation for MCJIT and I want to replace calls to Memory::AllocateRWX with calls to Memory::allocateMappedMemory, possibly still with the RWX flags.  However, looking at the Memory::AllocateRWX implementation I see that it’s jumping through some hoops in the case where both ‘__APPLE__’ and ‘__arm__’ are defined.
>  
> I want to handle two cases:
>  
> 1)      Allocate memory as RWX, copy JITed code into it and execute it without ever touching the permissions again.

ARM Darwin can't do this. Memory is never allowed to be both writable and executable at the same time.

> 2)      Allocate memory as RW, copy JITed code into it and then set the permissions to RX before executing.

This is the path that can work, if the JIT process has been appropriately blessed by the system. Normal applications can't do this (the vm_protect() will fail transitioning from writable to executable).

>  This seems pretty straight-forward with the functions that use mmap and mprotect, but the AllocateRWX implementation leads me to believe that won’t work in the ARM+Apple case.  I read some vm_protect documentation, but I can’t quite reconcile it with the AllocateRWX implementation.
>  
> My goal is to make sure the Memory::allocateMappedMemory and Memory::protectMappedMemory functions will work everywhere.
>  
> Any suggestions?
>  
> Thanks,
> Andy
>  
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121116/850c5d59/attachment.html>


More information about the llvm-dev mailing list