search for: sectionmemorymanager

Hi, I am studying the llvm code and I noticed something that looks like a bug. If it is intentional for some reason, it is not obvious why. In lib/ExecutionEngine/SectionMemoryManager.cpp in SectionMemoryManager::finalizeMemory method: // Make code memory executable. ec = applyMemoryGroupPermissions(CodeMem, sys::Memory::MF_READ | sys::Memory::MF_EXEC); ... // Make read-only data memory read-only. ec = applyMemoryGroupPermissions(RODataMem,...

Hi Brian, On 29/07/13 23:42, Brian Herman wrote: > I got the following error while compiling llvm and clang under cygwin. > > /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/lib/libLLVMMCJIT.a(SectionMemoryManager.o):SectionMemoryManager.cpp:(.text+0x3b): > undefined reference to `__register_frame' I register_frame is used to enable the debugger (gdb) to debug JIT'd code. It is a function provided by libgcc, to be more precise in libgcc_eh. Is it in your copy? $ nm libgcc_eh.a | grep register_...

On Saturday, 15 July 2017 05:46:35 CEST 陳韋任 wrote: > SectionMemoryManager allocates executable memory section for MCJIT > (JIT emit code then execute). > So the bottomline is making the section sys::Memory::MF_EXEC. As for > RODataMem, we also need > to make sure it's read-only. You can compare it to RWDataMem, which > has write permission. That makes...

I got the following error while compiling llvm and clang under cygwin. /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/lib/libLLVMMCJIT.a(SectionMemoryManager.o):SectionMemoryManager.cpp:(.text+0x3b): undefined reference to `__register_frame' /cygdrive/c/Users/brianherman/Desktop/llvm/llvm-3.3.src/Release+Asserts/lib/libLLVMMCJIT.a(SectionMemoryManager.o):SectionMemoryManager.cpp:(.text+0x3b): relocation truncated to fit: R_X86_64_PC32 against undefi...

Hi 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 symbo...

...uot;Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > Hi 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 da...

..., "Kaylor, Andrew" <andrew.kaylor at intel.com> wrote: > Hi 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...

Thanks! Currently using MCJIT. But migration to ORC is on my TODO list. - Paweł On Thu, May 12, 2016 at 8:30 PM Lang Hames <lhames at gmail.com> wrote: > Hi Pawel, > > Option (1) and (3) are very similar, but using custom resolution (option > 3) guarantees that JIT'd code can't accidentally end up depending on > functions in your JIT that you didn't mean to

...ree.fr> wrote: > Hi Brian, > > > On 29/07/13 23:42, Brian Herman wrote: > >> I got the following error while compiling llvm and clang under cygwin. >> >> /cygdrive/c/Users/brianherman/**Desktop/llvm/llvm-3.3.src/** >> Release+Asserts/lib/**libLLVMMCJIT.a(**SectionMemoryManager.o):** >> SectionMemoryManager.cpp:(.**text+0x3b): >> undefined reference to `__register_frame' >> > > I register_frame is used to enable the debugger (gdb) to debug JIT'd code. > It > is a function provided by libgcc, to be more precise in libgcc_eh. Is it &g...

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 also tried disabling the MemGroup.FreeMem cache which did not matter. An added assert for no Stubs to the...

...acc4d7e..41a7c99413b 100644 --- a/tools/lli/OrcLazyJIT.h +++ b/tools/lli/OrcLazyJIT.h @@ -62,7 +62,11 @@ public:               bool InlineStubs)        : TM(std::move(TM)), DL(this->TM->createDataLayout()),         CCMgr(std::move(CCMgr)), -       ObjectLayer([]() { return std::make_shared<SectionMemoryManager>(); }), +       ObjectLayer([]() { return std::make_shared<SectionMemoryManager>(); }, +              [this](llvm::orc::RTDyldObjectLinkingLayerBase::ObjHandleT, +                     const llvm::orc::RTDyldObjectLinkingLayerBase::ObjectPtr &obj, +                     const llvm::Runti...

...ndrew.kaylor at intel.com> wrote: > >> Hi 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 ext...

...way to get call stacks to the generated code (though if you want to try it on Linux, that should work). You can probably look at the address where the crash is occurring and verify that it is in the generated code. There are a couple of things I would look for. First, I'd take a look at the SectionMemoryManager allocation handling. The fact that the problem is code size dependent strongly points in this direction. It may be that SectionMemoryManager does something wrong when it hits a page boundary or something. Second, I'd look at the relocation processing. If it is generating any stubs, that wou...

...ace (default is 10M) for the compiled program without any change. Yaron 2013/10/22 Kaylor, Andrew <andrew.kaylor at intel.com> > I’m not aware of such a limitation.**** > > ** ** > > What architecture, code model and relocation model are you using? Are you > using the SectionMemoryManager?**** > > ** ** > > -Andy**** > > ** ** > > *From:* Yaron Keren [mailto:yaron.keren at gmail.com] > *Sent:* Tuesday, October 22, 2013 8:12 AM > *To:* <llvmdev at cs.uiuc.edu>; Kaylor, Andrew > *Subject:* Size limitations in MCJIT / ELF Dynamic Linker/ ELF codeg...

...that > the full list of modules and their content are not available at a time > when some of jitted pieces are already in use. We do this in our project, using MCJIT. > Is it feasible to destruct ExecutionEngine but keep jitted code alive? Yes; we use our own memory manager, extending SectionMemoryManager (not JITMemoryManager). An instance of the memory manager is created and destroyed with each ExecutionEngine, so we use it as a wrapper for our actual allocation mechanism; this allows the code/data lifetime to be managed independently of the ExecutionEngine and Module. > Are jitted binary cod...

Hi, Can you please clarify? We're looking for a way to use LLVM to JIT many modules, assuming that the full list of modules and their content are not available at a time when some of jitted pieces are already in use. Is it feasible to destruct ExecutionEngine but keep jitted code alive? Are jitted binary codes position independent? (or is there a way to relocate) If the solution requires

...rew Cc: <llvmdev at cs.uiuc.edu> Subject: Re: Size limitations in MCJIT / ELF Dynamic Linker/ ELF codegen? 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 also tried disabling the MemGroup.FreeMem cache which did not matter. An added assert for no Stubs to the...

...ted by the ORC JIT so that I can save them to disk and in later sessions reload them. (2) How would I pass an ObjectFile saved in question#1 back to ORC so that it will relocate it and generate function pointers? (3) How do I get access to the relocated ObjectFile sections? Currently I subclass SectionMemoryManager and implement allocateDataSection(...) I can get the memory for the "__llvm_stackmaps" section - but I don't know when/if the contents have been fully set up with relocated function pointers. (4) For the "__llvm_stackmaps" section - will I need to do any relocation to ob...

...F > codegen?**** > > ** ** > > 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 > also tried disabling the MemGroup.FreeMem cache which did not matter.**** > > ** ** &...

...;> 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 >> also tried disabling the MemGroup.FreeMem cache which did not matter.**** >&...