search for: legacyrtdyldobjectlinkinglay

I have found the cause of our problems with implicit template instantiation, and it looks to me like a bug in Orc JIT in LLVM 8. (Perhaps Lang could confirm?) We use createLegacyLookupResolver() to create our symbol resolver, passing it a lookup function. Amongst other things, our function calls LegacyRTDyldObjectLinkingLayer::findSymbol() to look up symbols in the JIT. When a module is finalized, the legacy lookup resolver calls getResponsibilitySetWithLegacyFn() to find any symbols with weak linkage (e.g. function templates) that need to be materialized; that function calls our symbol resolver, which calls LegacyRT...

...t template >> instantiation, and it looks to me like a bug in Orc JIT in LLVM 8. >> (Perhaps Lang could confirm?) >> >> We use createLegacyLookupResolver() to create our symbol resolver, >> passing it a lookup function. Amongst other things, our function calls >> LegacyRTDyldObjectLinkingLayer::findSymbol() to look up symbols in the >> JIT. >> >> When a module is finalized, the legacy lookup resolver calls >> getResponsibilitySetWithLegacyFn() to find any symbols with weak >> linkage (e.g. function templates) that need to be materialized; that >> fun...

Well, I agree the front end must be responsible for (not) instantiating the function templates. However the problem shows up only when JIT compiling, for some reason, and only with LLVM 8. Is there perhaps something else that needs to be done before resolving symbols, in addition to running constructors, to ensure that instantiated function templates are taken into account? Or perhaps there is

...llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:311: llvm::Error llvm::orc::LegacyCompileOnDemandLayer<BaseLayerT, CompileCallbackMgrT, IndirectStubsMgrT>::removeModule(llvm::orc::VModuleKey) [with BaseLayerT = llvm::orc::LegacyIRTransformLayer<llvm::orc::LegacyIRCompileLayer<llvm::orc::LegacyRTDyldObjectLinkingLayer, llvm::orc::SimpleCompiler>, std::function<std::unique_ptr<llvm::Module>(std::unique_ptr<llvm::Module>)> >; CompileCallbackMgrT = llvm::orc::JITCompileCallbackManager; IndirectStubsMgrT = llvm::orc::IndirectStubsManager; llvm::orc::VModuleKey = long unsigned int]: Assertio...

...- is that correct? 2.) JITDyLib I think, but I'm not sure, that I can use a JITDyLib to inject my own addresses for different functions, but I'm not sure how to do that - or if I'm correct with it. 3.) Legacy Layer I later looked into the third Kaleidoscope Tutorial, seeing the "LegacyRTDyldObjectLinkingLayer" and "LegacyIRCompileLayer" - that looked promising! But sadly the tutorial state that it was not updated yet to the new OrcJIT API - so... I have difficulties 'trusting' that tutorial. Does it mean, that those Legacy Layer will be removed soon? Or that you should not use t...

...e I use a LegacyIRCompileLayer to search for the symbol in the jitted module. That function call eventually ends up in getSymbol in RTDyldObjectLinkingLayer.h where the symbol is found but it does not have and address (Address is zero and Flags is 50). So an instance of JITSymbol is returned to the LegacyRTDyldObjectLinkingLayer and the findSymbol function which checks if an valid symbol was found (on line 406 in RTDyldObjectLinkingLayer.h). Since the address is zero the JITSymbol is deemed to be not valid, via the bool operator in JITSymbol.h and that is why that particular symbol name does not end up in the Responsibil...

...mpileLayer to search for the symbol in the jitted module. That > function call eventually ends up in getSymbol in RTDyldObjectLinkingLayer.h > where the symbol is found but it does not have and address (Address is zero > and Flags is 50). So an instance of JITSymbol is returned to the > LegacyRTDyldObjectLinkingLayer and the findSymbol function which checks if > an valid symbol was found (on line 406 in RTDyldObjectLinkingLayer.h). > Since the address is zero the JITSymbol is deemed to be not valid, via the > bool operator in JITSymbol.h and that is why that particular symbol name > does not end u...

...mpileOnDemandLayer.h:311: llvm::Error >> llvm::orc::LegacyCompileOnDemandLayer<BaseLayerT, CompileCallbackMgrT, >> IndirectStubsMgrT>::removeModule(llvm::orc::VModuleKey) [with >> BaseLayerT = llvm::orc::LegacyIRTransformLayer<llvm::orc::LegacyIRCompileLayer<llvm::orc::LegacyRTDyldObjectLinkingLayer, >> llvm::orc::SimpleCompiler>, >> std::function<std::unique_ptr<llvm::Module>(std::unique_ptr<llvm::Module>)> >> >; CompileCallbackMgrT = llvm::orc::JITCompileCallbackManager; >> IndirectStubsMgrT = llvm::orc::IndirectStubsManager; >> llvm::o...