search for: objectlinkinglay

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 I can create my own ObjectLinkingLayer or some...

...nstance embedded at the bottom of the stack. 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 r...

Hi Lang, It turns out I also need an ability to tell the object linking layer not to apply any relocations. I need to skip this step below. The only way I can see I can achieve that is by creating my own ObjectLinkingLayer that would duplicate almost all of orc::ObjectLinkingLayer. 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...

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, Eugene Rozenfeld < Eugene.Rozenfeld at microsoft.com> wrote: > Hi Lang, > > > > It turns out I also need an ability to tell the object linking layer not...

...tionEngine\Orc\IRCompileLayer.h template <typename BaseLayerT> class IRCompileLayer { JITSymbol findSymbol(const std::string &Name, bool ExportedSymbolsOnly) { return BaseLayer.findSymbol(Name, ExportedSymbolsOnly); } C:\llvm\examples\Kaleidoscope\Orc\initial\toy.cpp typedef ObjectLinkingLayer<> ObjLayerT; C:\llvm\include\llvm\ExecutionEngine\Orc\ObjectLinkingLayer.h JITSymbol findSymbol(StringRef Name, bool ExportedSymbolsOnly) { for (auto I = LinkedObjSetList.begin(), E = LinkedObjSetList.end(); I != E; ++I) if (auto Symbol = findSymbolIn(I, Name, Exporte...

...late <typename BaseLayerT> class IRCompileLayer { > > JITSymbol findSymbol(const std::string &Name, bool ExportedSymbolsOnly) { > return BaseLayer.findSymbol(Name, ExportedSymbolsOnly); > } > > C:\llvm\examples\Kaleidoscope\Orc\initial\toy.cpp > > typedef ObjectLinkingLayer<> ObjLayerT; > > C:\llvm\include\llvm\ExecutionEngine\Orc\ObjectLinkingLayer.h > > JITSymbol findSymbol(StringRef Name, bool ExportedSymbolsOnly) { > for (auto I = LinkedObjSetList.begin(), E = LinkedObjSetList.end(); I > != E; > ++I) > if (auto...

Trying to put together a simple test JIT compiler, using ORC which as I understand it will be the supported API going forward, I noticed that in the first chapter of the updated Kaleidoscope tutorial, there is sample code that starts like this: ExecutionSession ES; RTDyldObjectLinkingLayer ObjectLayer; IRCompileLayer CompileLayer; DataLayout DL; MangleAndInterner Mangle; ThreadSafeContext Ctx; But in https://llvm.org/devmtg/2016-11/Slides/Hames-ORC.pdf there is sample code that looks like this: ObjectLinkingLayer LinkLayer; SimpleCompiler Compiler(TargetMachine()); IRCompileLaye...

...on the big static initializer patch. Unfortunately issue #2 interacts with it, so I have to do some integration work before it is ready to land, but I'm hopeful that it will be ready some time next week. Finally, I have added a new example (bb7a5707ac0)to llvm/examples/LLJITExamples: LLJITWithObjectLinkingLayerPlugin demonstrating how to write a custom ObjectLinkingLayer plugin. ObjectLinkingLayer plugins can be used to receive and respond to events in the linking layer, and to inspect and modify JITLink LinkGraphs during the linking process. ORC uses this internally to register EH frames, but the syste...

Dear Geoff, As for as ORCv2 is concerned, there is no event listener facility available as of now. Thanks On Fri, 20 Dec 2019 at 01:21, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +Lang Hames <lhames at gmail.com> the author/owner of the ORC JIT - though > he's out of teh office at the moment I think, so might not get a reply > until the new year

Hi All, The initializer patch review at https://reviews.llvm.org/D74300 has been updated. The new version contains a MachOPlatform implementation that demonstrates how Platforms and ObjectLinkingLayer::Plugins can work together to implement platform specific initialization. In this case, the MachOPlatform installs a plugin that scans objects for __objc_classlist and __objc_selref sections and uses them to register JIT'd code with the Objective-C runtime. This allows LLJIT instances (and th...

...into the JIT from an object file or static library...? Sure! Are you interested in doing this with the C API, LLJIT, or raw OrcV2 components? The high-level answer here (which we can dig into further in the BoF) is: For object files: - For raw OrcV2 components you'll want to create an RTDyldObjectLinkingLayer or ObjectLinkingLayer and use the 'add' method. - For an LLJIT instance you can just call the 'addObjectFile' method. - For the OrcV2 C API you can call the 'LLVMOrcLLJITAddObjectFile' function. For static libraries: - For raw OrcV2 components or an LLJIT instance you can...

...3 AM, Eugene Rozenfeld <Eugene.Rozenfeld at microsoft.com<mailto:Eugene.Rozenfeld at microsoft.com>> wrote: Hello, I’m working on LLILC (a jit for the CoreCLR built on ORC), in particular, on using LLILC as an ngen jit. I would like to have an 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...

...cV2 that I didn't see with V1. I'm not yet > > sure where exactly they're coming from. Possible that I'm just missing a > > step somewhere. Or something around the removable code support doesn't > > yet fully work. > > I just checked and I've migrated ObjectLinkingLayer to support > ResourceTracker, but not RTDyldObjectLinkingLayer yet. If you're testing on > Linux there's a good chance that's the source of your leak. I'll get that > updated tonight. I indeed am testing on linux... Thanks. Regards, Andres

...ure! Are you interested in doing this with the C API, LLJIT, or raw > OrcV2 components? > > > > The high-level answer here (which we can dig into further in the BoF) is: > > > > For object files: > > - For raw OrcV2 components you'll want to create an > RTDyldObjectLinkingLayer or ObjectLinkingLayer and use the 'add' method. > > - For an LLJIT instance you can just call the 'addObjectFile' method. > > - For the OrcV2 C API you can call the 'LLVMOrcLLJITAddObjectFile' > function. > > > > For static libraries: > > -...

...make that easier. Possibly too complicated for that type of session? We couldn't go into detail, but we could kick off a discussion and identify who is interested in working on this. My pitch: We should solve this by investing in JITLink and implementing profiling (and debugger support) via ObjectLinkingLayer::Plugins. Maybe a brief overview of / discussion on how these work would be useful? -- Lang. On Fri, Sep 25, 2020 at 7:19 PM Andres Freund <andres at anarazel.de> wrote: > Hi, > > On 2020-09-25 19:05:42 -0700, Lang Hames wrote: > > The 2020 Virtual LLVM Developer's Me...

...cutionEngine/ExecutionEngine.h> #include <llvm/ExecutionEngine/Orc/CompileUtils.h> #include <llvm/ExecutionEngine/RuntimeDyld.h> #include <llvm/ExecutionEngine/Orc/IRCompileLayer.h> #include <llvm/ExecutionEngine/Orc/LambdaResolver.h> #include <llvm/ExecutionEngine/Orc/ObjectLinkingLayer.h> #include <llvm/IR/DataLayout.h> #include <llvm/IR/IRBuilder.h> #include <llvm/IR/LegacyPassManager.h> #include <llvm/IR/LLVMContext.h> #include <llvm/IR/Mangler.h> #include <llvm/IR/Module.h> #include <llvm/IR/Verifier.h> #include <llvm/Support/T...

...ocationList(const llvm::SmallVector<llvm::RelocationEntry,64> & Relocs, unsigned __int64 Value) Line 796 C++ llvm::RuntimeDyldImpl::resolveExternalSymbols() Line 849 C++ llvm::RuntimeDyldImpl::resolveRelocations() Line 95 C++ llvm::RuntimeDyld::resolveRelocations() Line 961 C++ llvm::orc::ObjectLinkingLayer<llvm::orc::DoNothingOnNotifyLoaded>::ConcreteLinkedObjectSet<std::shared_ptr<llvm::SectionMemoryManager>,ClangClasses::LLVMExecutionEngine::LinkingResolver * __ptr64>::Finalize() Line 112 C++ llvm::orc::ObjectLinkingLayer<llvm::orc::DoNothingOnNotifyLoaded>::findSymbolIn::...

Hello, I'm working on LLILC (a jit for the CoreCLR built on ORC), in particular, on using LLILC as an ngen jit. I would like to have an 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...

...ested in and hope to make some progress on in tree in the not too distant future. -- Lang. On Mon, Oct 9, 2017 at 12:27 PM, Jameson Nash via llvm-dev < llvm-dev at lists.llvm.org> wrote: > That is correct – there is no built-in support. You have to provide your > own Registrar to the ObjectLinkingLayer to provide this sort of > functionality. (For example JuliaLang does that at https://github.com/ > JuliaLang/julia/blob/1216e5f60cd2b23e29856b5227399a > b0f3abef76/src/jitlayers.cpp#L437, in addition to registering the > function pointer and object file info in several other places)....

Hi, On 2020-09-30 17:52:46 -0700, Lang Hames wrote: > I've just realised that we're going to need a change to the definition > generator API in the long term: Right now it is called under the session > lock, but we want to shift to calling it outside the lock and passing a > lookup-continuation. This would allow definition discovery to take an > arbitrarily long time