search for: allocatemappedmemory

Hi! Implementing the Memory::allocateMappedMemory() function on z/OS, I see a failure in the AArch64 COFF test case. The test case has 3 sections. For each section, Memory::allocateMappedMemory() is called to reserve memory. If the distance between the pointers gets too large, then the test case fails. It can be reliable produced with a distanc...

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) Allocate memory as RWX, copy JITed code...

...; <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 cod...

...fixes this, and checks that both read and write flags are set. unittests/Support/MemoryTest.cpp (line 101) TEST_P(MappedMemoryTest, BasicWrite) { // This test applies only to writeable combinations if (Flags && !(Flags & Memory::MF_WRITE)) return; MemoryBlock M1 = Memory::allocateMappedMemory(sizeof(int), 0, Flags, EC); ... int *a = (int*)M1.base(); *a = 1; EXPECT_EQ(1, *a); // This line segfaults. ... } -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121204/67fd4245/attachment.html>...

...at intel.com<mailto: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...

...David, Following up on the problems we discussed yesterday on IRC regarding TLS with MCJIT, I've put together the attached experimental patch. This patch makes three changes: 1. SectionMemoryManager is changed to request memory below the 2GB boundary by default. 2. sys::Memory::allocateMappedMemory is changed to set the MAP_32BIT flag if the requested "near" block is below the 2GB boundary. 3. RuntimeDyldELF is changed to recognize the possibility of external data symbols. Of these changes, items 2 and 3 are probably reasonable things to commit into trunk, and depending on h...

...fixes this, and checks that both read and write flags are set. unittests/Support/MemoryTest.cpp (line 101) TEST_P(MappedMemoryTest, BasicWrite) { // This test applies only to writeable combinations if (Flags && !(Flags & Memory::MF_WRITE)) return; MemoryBlock M1 = Memory::allocateMappedMemory(sizeof(int), 0, Flags, EC); ... int *a = (int*)M1.base(); *a = 1; EXPECT_EQ(1, *a); // This line segfaults. ... } -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121205/a503d7e4/attachment.html>

...gt; 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 cod...

...he problems we discussed yesterday on IRC regarding TLS with MCJIT, I've put together the attached experimental patch. > > This patch makes three changes: > > 1. SectionMemoryManager is changed to request memory below the 2GB boundary by default. > 2. sys::Memory::allocateMappedMemory is changed to set the MAP_32BIT flag if the requested "near" block is below the 2GB boundary. > 3. RuntimeDyldELF is changed to recognize the possibility of external data symbols. > > Of these changes, items 2 and 3 are probably reasonable things to commit into trunk, and...

...on the problems we discussed yesterday on IRC regarding TLS with MCJIT, I’ve put together the attached experimental patch. > > This patch makes three changes: > > 1. SectionMemoryManager is changed to request memory below the 2GB boundary by default. > 2. sys::Memory::allocateMappedMemory is changed to set the MAP_32BIT flag if the requested “near” block is below the 2GB boundary. > 3. RuntimeDyldELF is changed to recognize the possibility of external data symbols. > > Of these changes, items 2 and 3 are probably reasonable things to commit into trunk, and depending...

...cussed yesterday on IRC regarding TLS with MCJIT, I've put together the attached experimental patch. >> >> This patch makes three changes: >> >> 1. SectionMemoryManager is changed to request memory below the 2GB boundary by default. >> 2. sys::Memory::allocateMappedMemory is changed to set the MAP_32BIT flag if the requested "near" block is below the 2GB boundary. >> 3. RuntimeDyldELF is changed to recognize the possibility of external data symbols. >> >> Of these changes, items 2 and 3 are probably reasonable things to commit into...

...> TLS with MCJIT, I've put together the attached experimental patch. > >> > >> This patch makes three changes: > >> > >> 1. SectionMemoryManager is changed to request memory below the > 2GB boundary by default. > >> 2. sys::Memory::allocateMappedMemory is changed to set the > MAP_32BIT flag if the requested "near" block is below the 2GB boundary. > >> 3. RuntimeDyldELF is changed to recognize the possibility of > external data symbols. > >> > >> Of these changes, items 2 and 3 are probably reasonab...

...cussed yesterday on IRC regarding TLS with MCJIT, I've put together the attached experimental patch. >> >> This patch makes three changes: >> >> 1. SectionMemoryManager is changed to request memory below the 2GB boundary by default. >> 2. sys::Memory::allocateMappedMemory is changed to set the MAP_32BIT flag if the requested "near" block is below the 2GB boundary. >> 3. RuntimeDyldELF is changed to recognize the possibility of external data symbols. >> >> Of these changes, items 2 and 3 are probably reasonable things to commit into...

...size limitations wasn't quite correct. If you have enough code and data that we end up putting sections at addresses that are more than 2GB apart we'll have problems, but you should see an assertion in that case. That can happen if we weren't able to get the address we requested from allocateMappedMemory, but it doesn't look like that's what's happening here. -Andy From: Yaron Keren [mailto:yaron.keren at gmail.com] Sent: Tuesday, October 22, 2013 1:41 PM To: Kaylor, Andrew Cc: <llvmdev at cs.uiuc.edu> Subject: Re: Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen? Hi...

...mitations > wasn’t quite correct. If you have enough code and data that we end up > putting sections at addresses that are more than 2GB apart we’ll have > problems, but you should see an assertion in that case. That can happen if > we weren’t able to get the address we requested from allocateMappedMemory, > but it doesn’t look like that’s what’s happening here.**** > > ** ** > > -Andy**** > > ** ** > > *From:* Yaron Keren [mailto:yaron.keren at gmail.com] > *Sent:* Tuesday, October 22, 2013 1:41 PM > > *To:* Kaylor, Andrew > *Cc:* <llvmdev at cs.uiuc.edu&gt...

...t; wasn’t quite correct. If you have enough code and data that we end up >> putting sections at addresses that are more than 2GB apart we’ll have >> problems, but you should see an assertion in that case. That can happen if >> we weren’t able to get the address we requested from allocateMappedMemory, >> but it doesn’t look like that’s what’s happening here.**** >> >> ** ** >> >> -Andy**** >> >> ** ** >> >> *From:* Yaron Keren [mailto:yaron.keren at gmail.com] >> *Sent:* Tuesday, October 22, 2013 1:41 PM >> >> *To:* Kaylor,...

...t; wasn’t quite correct. If you have enough code and data that we end up >> putting sections at addresses that are more than 2GB apart we’ll have >> problems, but you should see an assertion in that case. That can happen if >> we weren’t able to get the address we requested from allocateMappedMemory, >> but it doesn’t look like that’s what’s happening here.**** >> >> ** ** >> >> -Andy**** >> >> ** ** >> >> *From:* Yaron Keren [mailto:yaron.keren at gmail.com] >> *Sent:* Tuesday, October 22, 2013 1:41 PM >> >> *To:* Kaylor,...

...ite correct. If you have enough code and data that we end up >>> putting sections at addresses that are more than 2GB apart we’ll have >>> problems, but you should see an assertion in that case. That can happen if >>> we weren’t able to get the address we requested from allocateMappedMemory, >>> but it doesn’t look like that’s what’s happening here.**** >>> >>> ** ** >>> >>> -Andy**** >>> >>> ** ** >>> >>> *From:* Yaron Keren [mailto:yaron.keren at gmail.com] >>> *Sent:* Tuesday, October 22, 2013...

...ite correct. If you have enough code and data that we end up >>> putting sections at addresses that are more than 2GB apart we’ll have >>> problems, but you should see an assertion in that case. That can happen if >>> we weren’t able to get the address we requested from allocateMappedMemory, >>> but it doesn’t look like that’s what’s happening here.**** >>> >>> ** ** >>> >>> -Andy**** >>> >>> ** ** >>> >>> *From:* Yaron Keren [mailto:yaron.keren at gmail.com] >>> *Sent:* Tuesday, October 22, 2013...

Hi, Thanks for your ideas. Memory allocation already exceeds 2x64K in the "working" case so it's not the condition of allocating more than 64K. To be sure I had modified SectionMemoryManager::allocateSection to allocate four time the required memory but it did not trigger more crashes.I debugged through the allocation code including the Win32 code and it seems to work well. I have