search for: finalizememory

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, sys::Memory::...

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 sense. My question is

...tion" are allocating local non-shared memory. I store there addresses in a std::vector. When the function "notifyObjectLoaded" is invoked, I allocate the shared memory - I'm getting the size from the local non-shared memory - and apply the address mapping. When the function "finalizeMemory" is invoked I copy the code from the local non-shared memory to the shared memory but only one time. So far so good, this works actually good! Yippie x3 BUT... There is one problem. The shared memory can't be dynamical adjusted. So if I add another module to the current module, then I wo...

...mimic the memory size calculations performed by RuntimeDyld, then pre-allocate the memory yourself. BUT... There is one problem. The shared memory can't be dynamical adjusted. > So if I add another module to the current module, then I would go through > this process again! Not the "finalizeMemory" process though, but I would > allocate another shared memory. This is not what I want! Currently I use > the linker first, to work around this problem, but this will not help me if > I add object files or libraries to the JIT process - or does it? Unless all of your code is pre-com...

...Note that it still uses LegacyJITSymbolResolver, so I guess it may change any time soon. Hope it helps for the time being. Cheers, Stefan Am 05.11.18 um 19:44 schrieb Christian Schafmeister via llvm-dev: > I think I found the answer to #3 and #4. > (a) I overloaded the SectionMemoryManager::finalizeMemory(...) method.  > (b) I first call the base classes method (maybe not necessary). > (c) At this point the __llvm_stackmaps section that I saved in thread > local memory when allocateDataSection was called appears to be fully > set up and relocated. > > > On Mon, Nov 5, 2018 at 12...

...AbortOnFailure=true) { return mgr()->getPointerToNamedFunction(Name, AbortOnFailure); } #if HAVE_LLVM == 0x0303 virtual bool applyPermissions(std::string *ErrMsg = 0) { return mgr()->applyPermissions(ErrMsg); } #elif HAVE_LLVM > 0x0303 virtual bool finalizeMemory(std::string *ErrMsg = 0) { return mgr()->finalizeMemory(ErrMsg); } #endif };

...return mgr()->getPointerToNamedFunction(Name, AbortOnFailure); > } > #if HAVE_LLVM == 0x0303 > virtual bool applyPermissions(std::string *ErrMsg = 0) { > return mgr()->applyPermissions(ErrMsg); > } > #elif HAVE_LLVM > 0x0303 > virtual bool finalizeMemory(std::string *ErrMsg = 0) { > return mgr()->finalizeMemory(ErrMsg); > } > #endif > }; > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/l...

...rToNamedFunction(Name, AbortOnFailure); >> } >> #if HAVE_LLVM == 0x0303 >> virtual bool applyPermissions(std::string *ErrMsg = 0) { >> return mgr()->applyPermissions(ErrMsg); >> } >> #elif HAVE_LLVM > 0x0303 >> virtual bool finalizeMemory(std::string *ErrMsg = 0) { >> return mgr()->finalizeMemory(ErrMsg); >> } >> #endif >> }; >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> ht...

...tly, it's possible that calling finalizeObject more than once would cause a crash. The changes that introduced multiple module support should have fixed that issue. It might be useful to set breakpoints in the memory manager you are using. During finalizeObject you are likely to see calls to finalizeMemory, getSymbolAddress, registerEHFrames and notifyObjectLoaded. I think registerEHFrames is the most likely source of the problem, particularly given that the debugger is also crashing. If that's the problem, you could probably get a little further (for experimental purposes at least) by just hav...

...ng malloc, or inheriting from SectionMemoryManager and capturing the allocation details) (b) Override the notifyObjectLoaded method to allocate the final memory locations, then call RTDyldMemoryManager::mapSectionAddress to map each local allocation to its corresponding final address (c) Override finalizeMemory to copy the relocated bytes to their final addresses Hope this helps. Cheers, Lang. On Tue, May 2, 2017 at 10:47 PM, <bjoern.gaier at horiba.com> wrote: > Hello Lang, > > your answer explained a lot to me, thank you for that. Do you know if > there is a way to obtain the f...

...SymbolResolverPtrT Resolver) : LinkedObjectSet(*MemMgr, *Resolver), MemMgr(std::move(MemMgr)), Resolver(std::move(Resolver)) { } void Finalize() override { State = Finalizing; RTDyld->resolveRelocations(); RTDyld->registerEHFrames(); MemMgr->finalizeMemory(); OwnedBuffers.clear(); State = Finalized; } From: Lang Hames [mailto:lhames at gmail.com] Sent: Friday, July 3, 2015 6:36 PM To: Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com> Cc: llvmdev at cs.uiuc.edu Subject: Re: ORC and relocations Hi Eugene, Sorry for the dela...

I have a few questions about the new ORC JIT. I saw Lang Hames (hi!) excellent talk at the llvm-dev meeting a few weeks ago. The ORC JIT is undergoing some API changes and I'd like/need to take advantage of them. (1) How do I take ownership of the ObjectFile once the ORC JIT has created it? I'd like to take ownership of object files generated by the ORC JIT so that I can save them to

...Resolver), MemMgr(std::move(MemMgr)), > > Resolver(std::move(Resolver)) { } > > > > void Finalize() override { > > State = Finalizing; > > RTDyld->resolveRelocations(); > > RTDyld->registerEHFrames(); > > MemMgr->finalizeMemory(); > > OwnedBuffers.clear(); > > State = Finalized; > > } > > > > > > *From:* Lang Hames [mailto:lhames at gmail.com] > *Sent:* Friday, July 3, 2015 6:36 PM > *To:* Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com> > *Cc:* llvmde...

...SymbolResolverPtrT Resolver) : LinkedObjectSet(*MemMgr, *Resolver), MemMgr(std::move(MemMgr)), Resolver(std::move(Resolver)) { } void Finalize() override { State = Finalizing; RTDyld->resolveRelocations(); RTDyld->registerEHFrames(); MemMgr->finalizeMemory(); OwnedBuffers.clear(); State = Finalized; } From: Lang Hames [mailto:lhames at gmail.com<mailto:lhames at gmail.com>] Sent: Friday, July 3, 2015 6:36 PM To: Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com<mailto:Eugene.Rozenfeld at microsoft.com>> Cc: llvmd...

I'm trying to build LLVM on Android rather than the other way around! Really just to see if it can be done. I worked out the first problem (my code was written for the old JIT and I'd missed something in updating to the MCJIT to make it work on ARM). It still doesn't work, but at this point I have no idea why and it'll be a while before I get to look at it again: the Android

...Resolver), MemMgr(std::move(MemMgr)), > > Resolver(std::move(Resolver)) { } > > > > void Finalize() override { > > State = Finalizing; > > RTDyld->resolveRelocations(); > > RTDyld->registerEHFrames(); > > MemMgr->finalizeMemory(); > > OwnedBuffers.clear(); > > State = Finalized; > > } > > > > > > *From:* Lang Hames [mailto:lhames at gmail.com] > *Sent:* Friday, July 3, 2015 6:36 PM > *To:* Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com> > *Cc:* llvmde...

...ister Objective-C runtime. I decided to iterate on JIT code again and somehow I found that I can hook into SectionMemory by subclassing it and working with its allocateDataSection method: 1) I collect pointers to objc-related sections for which the memory is allocated. Before SectionMemoryManager::finalizeMemory() method is called I register the ObjC runtime classes. 2) I iterate over __objc_selrefs sections and fixup selectors. This does fix the original crash of this thread. 3) I iterate over __objc_classlist sections and register the new classes using objc_allocateClassPair function, register the proper...

Hi David, Stanislav, Sorry for the delayed reply. Short version: There hasn't been any progress on this just yet, as I have been busy with an overhaul of the underlying ORC APIs. 1) Hack up something in RuntimeDyldMachO to handle the data structures > currently generated by clang. This is fragile, because the interface > between the compiler and the runtime is not documented, and is

...e. I decided to iterate on JIT code > again and somehow I found that I can hook into SectionMemory by > subclassing it and working with its allocateDataSection method: > > 1) I collect pointers to objc-related sections for which the memory is > allocated. Before SectionMemoryManager::finalizeMemory() method is > called I register the ObjC runtime classes. > 2) I iterate over __objc_selrefs sections and fixup selectors. This > does fix the original crash of this thread. > 3) I iterate over __objc_classlist sections and register the new > classes using objc_allocateClassPair func...

Hi Lang, Yes, I can return a non-zero marker value. Are you ok with this version? void RuntimeDyldImpl::resolveExternalSymbols() { while (!ExternalSymbolRelocations.empty()) { StringMap<RelocationList>::iterator i = ExternalSymbolRelocations.begin(); StringRef Name = i->first(); if (Name.size() == 0) { // This is an absolute symbol, use an address of zero.