search for: resolvereloc

...Bad permissions for mapped region at address 0xEAF02F7 ==27130== at 0xEAF031F: llvm::RuntimeDyldELF::resolveX86_64Relocation(llvm::SectionEntry const&, unsigned long, unsigned long, unsigned int, long, unsigned long) (RuntimeDyldELF.cpp:213) ==27130== by 0xEAF260F: llvm::RuntimeDyldELF::resolveRelocation(llvm::SectionEntry const&, unsigned long, unsigned long, unsigned int, long, unsigned long) (RuntimeDyldELF.cpp:798) ==27130== by 0xEAF258F: llvm::RuntimeDyldELF::resolveRelocation(llvm::RelocationEntry const&, unsigned long) (RuntimeDyldELF.cpp:787) ==27130== by 0xEAE7C67: llvm:...

Yes, I’m handling all internal and external relocations manually in NotifyLoadedFtor and I already verified that I get the behavior I need if I comment out the call to resolveRelocations. I would like to reuse ObjectLinkingLayer::addObjectSet (which eventually calls RuntimeDyld::loadObject), which has the right calls to the memory manager and also RuntimeDyld::registerEHFrames. I understand that resolveRelocations is normally the main job of ObjectLinkingLayer and as I said...

...egion at address 0xEAF02F7 > ==27130== at 0xEAF031F: > llvm::RuntimeDyldELF::resolveX86_64Relocation(llvm::SectionEntry const&, > unsigned long, unsigned long, unsigned int, long, unsigned long) > (RuntimeDyldELF.cpp:213) > ==27130== by 0xEAF260F: > llvm::RuntimeDyldELF::resolveRelocation(llvm::SectionEntry const&, unsigned > long, unsigned long, unsigned int, long, unsigned long) > (RuntimeDyldELF.cpp:798) > ==27130== by 0xEAF258F: > llvm::RuntimeDyldELF::resolveRelocation(llvm::RelocationEntry const&, > unsigned long) (RuntimeDyldELF.cpp:787) > ==...

...That's why addModuleSet takes a MemoryManager and SymbolResolver. If there's no RuntimeDyld instance at the bottom of the stack, it's not obvious that the interface should require those). For now I recommend just creating a local copy of the ObjectLinkingLayer and removing the call to resolveRelocations. I'll keep thinking about the best way to support this use case going forward. Cheers, Lang. On Wed, Jul 22, 2015 at 11:51 PM, Eugene Rozenfeld < Eugene.Rozenfeld at microsoft.com> wrote: > Yes, I’m handling all internal and external relocations manually in > NotifyLoaded...

Hi Eugene, Skipping the call to resolveRelocations would disable many (if not all) internal relocations too. Is that the desired behavior? At that point there's not much left for RuntimeDyld (or the ObjectLinkingLayer) to do. Would something like a NoopLinkingLayer be a workable solution? Cheers, Lang. On Wed, Jul 22, 2015 at 7:26 PM,...

...ConcreteLinkedObjectSet(MemoryManagerPtrT MemMgr, 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 a...

...t; + *Target = *Placeholder + Value + Addend - FinalAddress; + break; I''d like to make my new JIT APIs more aggressive about freeing the ObjectFile instances (ideally we'd be able to free immediately after a call to loadObject), but at the moment I have to hold it at least until resolveRelocations is called. I had a quick chat with Tim Northover about this and our guess was that it had something to do with relocations being applied more than once? Cheers, Lang. On Mon, Aug 19, 2013 at 4:27 PM, Andrew Kaylor <andrew.kaylor at intel.com<mailto:andrew.kaylor at intel.com>>...

...f for this that I'm not supposed to get 32 bit relocations in the code I'm building rather than all the code being loaded. The LLVM side of the call stack looks like this: _wassert(const wchar_t * expr, const wchar_t * filename, unsigned int lineno) Line 369 C llvm::RuntimeDyldCOFFX86_64::resolveRelocation(const llvm::RelocationEntry & RE, unsigned __int64 Value) Line 81 C++ llvm::RuntimeDyldImpl::resolveRelocationList(const llvm::SmallVector<llvm::RelocationEntry,64> & Relocs, unsigned __int64 Value) Line 796 C++ llvm::RuntimeDyldImpl::resolveExternalSymbols() Line 849 C++ llvm::R...

...moveDeadPasses(). For 10k iterations, the test took about 12.6s, or 1.26ms per module, so there's definitely some slowdown happening. Looking at the profiling output, it looks like the main difference is the appearance of MCJIT::finalizeLoadedModules(), which ultimately calls RuntimeDyldImpl::resolveRelocations() and SectionMemoryManager::applyMemoryGroupPermissions(), both of which iterate over all memory sections leading to quadratic overhead. I'm not sure how easy it would be, but it seems like there could be single-module variants of these apis that could cut down on the overhead, since it...

Hi Matt, Philip, You could get the data you want by recording the addresses returned by the allocateCodeSection and allocateDataSection methods on your RTDyldMemoryManager, then disassembling those sections after you've called resolveRelocations. That's a little unsatisfying though. For one thing, unless you very carefully maintain the association with the original object via back-channels there will be no way of knowing which section belongs to which object file. With a bit of cleanup though, we could do something more like thi...

...or 10k iterations, the test took about 12.6s, or 1.26ms per module, so > there's definitely some slowdown happening. Looking at the profiling > output, it looks like the main difference is the appearance of > MCJIT::finalizeLoadedModules(), which ultimately calls > RuntimeDyldImpl::resolveRelocations() and > SectionMemoryManager::applyMemoryGroupPermissions(), both of which iterate > over all memory sections leading to quadratic overhead. I'm not sure how > easy it would be, but it seems like there could be single-module variants > of these apis that could cut down on the...

...ic failures. I think by fixing PR16013 we'll enable support for remote mcjit on arm, and can then remove the xfails altogether. In the meantime, marking the tests as unsupported seems to be the best option. I don't have a machine for a few days but I can take a look at finally cleaning up resolveRelocations() next week. Amara > Both A9 bots are running the same Ubuntu (13.03), with the same GCC (4.7.2), > and are the same hardware (Panda ES RevB), so it really strikes me as odd > that we have such a different behaviour between them. Hmm. I'll see what I can do on my tablet (not t...

...dylib, _ZN11StaticStuffIiE6s is correctly picked up from the dylib. I would expect MCJIT to behave the same. I'll try to fix that myself, but I'd appreciate a hint where to do that. Should I collect linkonce_odr-s and "replace" their emitted code as part of llvm::RuntimeDyldImpl::resolveRelocations()? Or is this just a missing case somewhere? That's e.g. with $ lli --version LLVM (http://llvm.org/): LLVM version 3.6.0svn Optimized build. Built Jan 12 2015 (10:52:59). Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx Cheers, Axel.

...; the code I'm building rather than all the code being loaded. > > > > The LLVM side of the call stack looks like this: > > > > _wassert(const wchar_t * expr, const wchar_t * filename, unsigned int > lineno) Line 369 C > > llvm::RuntimeDyldCOFFX86_64::resolveRelocation(const llvm::RelocationEntry > & RE, unsigned __int64 Value) Line 81 C++ > > llvm::RuntimeDyldImpl::resolveRelocationList(const > llvm::SmallVector<llvm::RelocationEntry,64> & Relocs, unsigned __int64 > Value) Line 796 C++ > > llvm::RuntimeD...

> Both A9 bots are running the same Ubuntu (13.03), with the same GCC (4.7.2), > and are the same hardware (Panda ES RevB), so it really strikes me as odd > that we have such a different behaviour between them. Hmm. I'll see what I can do on my tablet (not tried building LLVM there before so it could take a while), it seems like there are *some* failures everywhere. If we're

...picked up > from the dylib. I would expect MCJIT to behave the same. > > I'll try to fix that myself, but I'd appreciate a hint where to do that. > Should I collect linkonce_odr-s and "replace" their emitted code as part > of llvm::RuntimeDyldImpl::resolveRelocations()? Or is this just a > missing case somewhere? > > That's e.g. with > > $ lli --version > LLVM (http://llvm.org/): > LLVM version 3.6.0svn > Optimized build. > Built Jan 12 2015 (10:52:59). > Default target: x86_64-un...

The MachO handling isn’t always straightforward in that it has a lot of bit fields to handle while it’s also trying to accommodate the format abstractions baked into the interfaces. The actual relocation type gets extracted in the RuntimeDyldMachO::resolveRelocation function (RuntimeDyldMachO.cpp:32) before it is passed on to the architecture-specific handlers. So the mask you mentioned is probably OK. The fact that this relocation type isn’t handled is, of course, the root of your problem. MCJIT has grown on an as-needed basis up to now, with only the...

Thanks for reply, it was really helpful. Can u just be more specific and tell about processRelocationRef() and resolveRelocation() in Targets/RuntimeDyld(objectfile format)(arch).h and also in RuntimeDyldELF.cpp and how the same function is implemented in different ways in both the files ? Thanks, Siddharth On Thu, Apr 20, 2017 at 8:16 PM, mats petersson <mats at planetcatfish.com> wrote: > (Again: Please alw...

...; <andrew.kaylor at intel.com> wrote: > The MachO handling isn’t always straightforward in that it has a lot of bit fields to handle while it’s also trying to accommodate the format abstractions baked into the interfaces. The actual relocation type gets extracted in the RuntimeDyldMachO::resolveRelocation function (RuntimeDyldMachO.cpp:32) before it is passed on to the architecture-specific handlers. So the mask you mentioned is probably OK. > > The fact that this relocation type isn’t handled is, of course, the root of your problem. > > MCJIT has grown on an as-needed basis up...

...ill get more attention. > > -- > Mats > > On 21 April 2017 at 14:54, Siddharth Shankar Swain < > h2015096 at pilani.bits-pilani.ac.in> wrote: > >> Thanks for reply, it was really helpful. Can u just be more specific and >> tell about processRelocationRef() and resolveRelocation() in >> Targets/RuntimeDyld(objectfile format)(arch).h and also in >> RuntimeDyldELF.cpp and how the same function is implemented in different >> ways in both the files ? >> Thanks, >> Siddharth >> >> On Thu, Apr 20, 2017 at 8:16 PM, mats petersson &lt...