search for: notifyloadedftor

Hi all, hi Lang It's a little late to report issues for release_50, but I just found that thing while porting my JitFromScratch examples to 5.0. This is a really nifty detail, but (if I'm not mistaken) the function signature of RTDyldObjectLinkingLayer::NotifyLoadedFtor is incorrect: $ grep -h -r -A 1 "using NotifyLoadedFtor" ./include/llvm/ExecutionEngine/Orc/RTDyldObjectLinkingLayer.h   using NotifyLoadedFtor = std::function<void(ObjHandleT, const ObjectPtr &Obj,                                               const LoadedObjectInfo &)>;  ...

...ability to be notified of relocations that ObjectLinkingLayer is applying and to be able to tell the linking layer not to resolve certain relocations for external symbols (so that the client can do some custom resolutions later). The only way I found of looking at relocations in the client is via NotifyLoadedFtor notifications but I couldn't find a way of blocking a relocation resolution. One way to achieve that is to change the Resolver::findSymbol api to allow clients to indicate that the relocations for the symbol shouldn't be resolved and update RuntimeDyldImpl::resolveExternalSymbols according...

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

...rom: Lang Hames [mailto:lhames at gmail.com] Sent: Wednesday, June 24, 2015 4:42 PM To: Eugene Rozenfeld Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu> Subject: Re: ORC and relocations Hi Eugene, There's no way to 'skip' application of a relocation. You could use the NotifyLoadedFtor and libObject to scan the object ahead of time and record the relocations that you'd like to override, then you could supply a custom Resolver that just returns '0' for the symbols that you want to handle manually. There's no way to handle distinct relocations for the same symbol d...

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

...I’d like to avoid that. An alternative it to pass a flag to orc::ObjectLinkingLayer constructor and orc::ObjectLinkingLayer::ConcreteLinkedObjectSet constructor to indicate whether relocation resolution should be performed. Would you be ok with such a change? Thanks, Eugene template <typename NotifyLoadedFtor = DoNothingOnNotifyLoaded> class ObjectLinkingLayer : public ObjectLinkingLayerBase { private: template <typename MemoryManagerPtrT, typename SymbolResolverPtrT> class ConcreteLinkedObjectSet : public LinkedObjectSet { public: ConcreteLinkedObjectSet(MemoryManagerPtrT MemMgr,...

...rom: Lang Hames [mailto:lhames at gmail.com] Sent: Wednesday, June 24, 2015 4:42 PM To: Eugene Rozenfeld Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu> Subject: Re: ORC and relocations Hi Eugene, There's no way to 'skip' application of a relocation. You could use the NotifyLoadedFtor and libObject to scan the object ahead of time and record the relocations that you'd like to override, then you could supply a custom Resolver that just returns '0' for the symbols that you want to handle manually. There's no way to handle distinct relocations for the same symbol d...

...gLayer constructor and > orc::ObjectLinkingLayer::ConcreteLinkedObjectSet constructor > > to indicate whether relocation resolution should be performed. Would you > be ok with such a change? > > > > Thanks, > > > > Eugene > > > > template <typename NotifyLoadedFtor = DoNothingOnNotifyLoaded> > > class ObjectLinkingLayer : public ObjectLinkingLayerBase { > > private: > > > > template <typename MemoryManagerPtrT, typename SymbolResolverPtrT> > > class ConcreteLinkedObjectSet : public LinkedObjectSet { > > publi...

...essing these issues, or is the position more generally that the C bindings aren't going to be useful enough? I'm willing to work on that, but only if there's actual interest in integrating things... I'm also a bit confused about RTDyldObjectLinkingLayer's notify integration. NotifyLoadedFtor is a class template parameter, but NotifyFinalizedFtor is just a std::function defaulting to empty? Is that just for historical raisins, or is there a deeper reason? To be able to use existing JITEventListeners - it'd surely be a shame to have to rewrite them anew - in custom stacks it also...

When we were using MCJIT, I could do this: // Attach the event listener Context.EE->RegisterJITEventListener( LLILCJitEventListener::createLLILCJitEventListener( new LLILCJitEventWrapper(&Context))); The event listeners listened for when an object is emitted (NotifyObjectEmitted), and that’s when we’d go through and extract debug info from the ObjectFile. Now, I imagine