search for: allocaterwx

Hi, Can anyone tell me something about mmap and vm_protect on ARM+Apple systems? 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)...

...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)...

"ARM Darwin can't do this. Memory is never allowed to be both writable and executable at the same time." That seems very sensible. So do the JIT engines just not work there now? Currently both MCJIT and JIT are using AllocateRWX which on that platform mmap's the memory as RX, then vm_protect's it as RX+VM_PROT_COPY, then vm_protect's it as RW. My best guess is that this is trying to set up something that's actually backed by two pages where whatever is written to the RW page will be copied to the RX page,...

...e time.” > > That seems very sensible. So do the JIT engines just not work there now? They work by allocating RW memory, then switching the permissions to RX before running any code stored there. That requires special process permissions. > > Currently both MCJIT and JIT are using AllocateRWX which on that platform mmap’s the memory as RX, then vm_protect’s it as RX+VM_PROT_COPY, then vm_protect’s it as RW. > > My best guess is that this is trying to set up something that’s actually backed by two pages where whatever is written to the RW page will be copied to the RX page, thoug...

Hello everyone, According to the release schedule, we're supposed to be tagging 'final' on Wednesday. Unfortunately, I suspect we will be a little late. There are currently 32 open release blockers: https://bugs.llvm.org/buglist.cgi?f1=blocked&o1=equals&v1=33849&query_format=advanced&resolution=--- Some of those have traction, but many don't. Some just need

...Only returning false constrains the emitter. > It's heap allocated so it may not be in the lower 4G > even if the code size model is small. I know this is the case on Darwin > x86_64, I am not sure about other targets. Oh, other targets can certainly allocate code above 4G too. sys::AllocateRWX just uses mmap with no constraints on the returned address, and I've got a Linux desktop where that always produces an address over 4G. > I forgot why this is needed for > tail calls, sorry. > > In theory we can make the code generator inline mov+call, the reality is it > doesn&...

On 17 Nov 2012, at 00:12, Kaylor, Andrew wrote: > My best guess is that this is trying to set up something that’s actually backed by two pages where whatever is written to the RW page will be copied to the RX page, though if that’s possible it would seem to defeat the purpose of not allowing RWX. The correct way of implementing this is to have one physical page mapped to two locations in

...on and check it in or submit patches to me and I'll check it in. Here's the details of my recent additions .. (1) Allocating RWX memory is used by the JIT Emitter for code generation and execution. The JIT software is now platform independent in this regard by using the new sys::Memory::AllocateRWX function. This function has been implemented to use variants of mmap on Unix platforms and VirtualAlloc on Win32. (2) The functions in "FileUtilities.h" for checking magic numbers and determining the type of a function have been added to the Path class. There are three new methods: has_m...

On Jun 10, 2009, at 12:17 PM, Jeffrey Yasskin wrote: > In X86CodeGen.cpp, the following code appears in the handler used for > CALL64pcrel32 instructions: > > // Assume undefined functions may be outside the Small > codespace. > bool NeedStub = > (Is64BitMode && > (TM.getCodeModel() == CodeModel::Large || >

In X86CodeGen.cpp, the following code appears in the handler used for CALL64pcrel32 instructions: // Assume undefined functions may be outside the Small codespace. bool NeedStub = (Is64BitMode && (TM.getCodeModel() == CodeModel::Large || TM.getSubtarget<X86Subtarget>().isTargetDarwin())) || Opcode == X86::TAILJMPd;

I've just wasted a day chasing my tail because of subtleties introduced to handle the optionality of the DataLayout. I would like to never do this again. =] We now have this attached to the Module with just a flimsy faked-up pass to keep APIs consistent. So, is there any problem with beginning down the path of: 1) Synthesizing a "default" boring DataLayout for all modules that