search for: exportedsymbolson

...Layer.findSymbol(Name, true); } CompileLayerT CompileLayer; typedef IRCompileLayer<ObjLayerT> CompileLayerT; C:\llvm\include\llvm\ExecutionEngine\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) {...

...t; CompileLayerT CompileLayer; > typedef IRCompileLayer<ObjLayerT> CompileLayerT; > > C:\llvm\include\llvm\ExecutionEngine\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 findSymb...

...dLayer. Does this alternative implementation of getLogicalModuleResourcesForSymbol work for you (unfortunately I don't have a local test case for this yet): LogicalModuleResources* getLogicalModuleResourcesForSymbol(const std::string &Name, bool ExportedSymbolsOnly) { for (auto LMI = LogicalModules.begin(), LME = LogicalModules.end(); LMI != LME; ++LMI) if (auto Sym = LMI->Resources.findSymbol(Name, ExportedSymbolsOnly)) return &LMI->Resources; return nullptr; } If so I'd be happy to commit this on your behalf...

...DL) { + std::string MangledName; + { + raw_string_ostream MangledNameStream(MangledName); + Mangler::getNameWithPrefix(MangledNameStream, Name, DL); + } + return MangledName; + } + + LogicalModuleResources* getLogicalModuleResourcesForSymbol(const std::string &Name, bool ExportedSymbolsOnly) { + for (auto LMI = LogicalModules.begin(), LME = LogicalModules.end(); + LMI != LME; ++LMI) + if (auto Sym = findSymbolInLogicalModule(LMI, mangle(Name,LMI->Resources.SourceModule->getResource().getDataLayout()), ExportedSymbolsOnly)) + return &LMI->Resourc...

...of > getLogicalModuleResourcesForSymbol work for you (unfortunately I don't > have a local test case for this yet): > > > > > > LogicalModuleResources* > getLogicalModuleResourcesForSymbol(const std::string &Name, > bool ExportedSymbolsOnly) { > for (auto LMI = LogicalModules.begin(), LME = LogicalModules.end(); > LMI != LME; ++LMI) > if (auto Sym = LMI->Resources.findSymbol(Name, ExportedSymbolsOnly)) > return &LMI->Resources; > return nullptr; > } > > If so I'd...

...{ > + raw_string_ostream MangledNameStream(MangledName); > + Mangler::getNameWithPrefix(MangledNameStream, Name, DL); > + } > + return MangledName; > + } > + > + LogicalModuleResources* getLogicalModuleResourcesForSymbol(const > std::string &Name, bool ExportedSymbolsOnly) { > + for (auto LMI = LogicalModules.begin(), LME = LogicalModules.end(); > + LMI != LME; ++LMI) > + if (auto Sym = findSymbolInLogicalModule(LMI, > mangle(Name,LMI->Resources.SourceModule->getResource().getDataLayout()), > ExportedSymbolsOnly)) > +...

...Symbol work for you (unfortunately I don't >> have a local test case for this yet): >> >> >> >> >> >> LogicalModuleResources* >> getLogicalModuleResourcesForSymbol(const std::string &Name, >> bool ExportedSymbolsOnly) { >> for (auto LMI = LogicalModules.begin(), LME = LogicalModules.end(); >> LMI != LME; ++LMI) >> if (auto Sym = LMI->Resources.findSymbol(Name, ExportedSymbolsOnly)) >> return &LMI->Resources; >> return nullptr; >> }...

...y to compose: class SomeLayer { private: // Implementation details public: // Implementation details typedef ??? Handle; template <typename ModuleSet> Handle addModuleSet(ModuleSet&& Ms); void removeModuleSet(Handle H); uint64_t getSymbolAddress(StringRef Name, bool ExportedSymbolsOnly); uint64_t lookupSymbolAddressIn(Handle H, StringRef Name, bool ExportedSymbolsOnly); }; Layers are usually designed to sit one-on-top-of-another, with each doing some sort of useful work before handing off to the layer below it. The layers that are currently included in the patch are the the...

...details > public: > Â // Implementation details > > Â typedef ??? Handle; > > Â template <typename ModuleSet> > Â Handle addModuleSet(ModuleSet&& Ms); > > Â void removeModuleSet(Handle H); > > Â uint64_t getSymbolAddress(StringRef Name, bool ExportedSymbolsOnly); > > Â uint64_t lookupSymbolAddressIn(Handle H, StringRef Name, bool > ExportedSymbolsOnly); > }; > > Layers are usually designed to sit one-on-top-of-another, with each > doing some sort of useful work before handing off to the layer below it. > The layers that are cu...

....": It would be nice to mention, where to find the include file: llvm-src/examples/Kaleidoscope/include/KaleidoscopeJIT.h - "auto ExprSymbol = TheJIT->findSymbol("__anon_expr");": On Windows, this will always fail as this function will search for "ExportedSymbolsOnly" and the exported flag seems to be implemented incorrectly for COFF in LLVM (see bug report from Russell Wallace: http://lists.llvm.org/pipermail/llvm-dev/2016-April/097964.html ). Applied to the current version of Kaleidoscope, he suggested to use "CompileLayer.findSymb...

...now there are people using ORC on Windows though, and evidently at least simple code works. I only know of one big gotcha, which is that COFF files don't properly handle the SF_Exported symbol flag, so whenever you go searching for a symbol in the JIT on windows you have to call findSymbol with ExportedSymbolsOnly=false. Other than that I don't think usage should differ too much between platforms. On the feature support side: the JIT linker for Windows (RuntimeDyldCOFF) is less mature, so you may run into unimplemented features there. While I don't have much time to work on Windows support myself,...

...now there are people using ORC on Windows though, and evidently at least simple code works. I only know of one big gotcha, which is that COFF files don't properly handle the SF_Exported symbol flag, so whenever you go searching for a symbol in the JIT on windows you have to call findSymbol with ExportedSymbolsOnly=false. Other than that I don't think usage should differ too much between platforms. > > On the feature support side: the JIT linker for Windows (RuntimeDyldCOFF) is less mature, so you may run into unimplemented features there. While I don't have much time to work on Windows suppo...

Agreed, that sounds like the best plan. I'll look into moving LLILC to ORC. Thanks -Joseph From: Russell Hadley Sent: Friday, May 29, 2015 8:13 PM To: Lang Hames; Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu Subject: RE: [LLVMdev] MCJit interface question Hey Joseph, What Lang said made me wonder. Is it the right time for us (LLILC) to move to ORC? The long term plan was to go there but

Thanks so much! This seems to do the trick. I would have spun my wheels for a long time before discovering all of this, wow. Do I even want to know what additional chickens need to be sacrificed to get this to work on Windows? -- lg > On May 18, 2016, at 1:52 PM, Lang Hames <lhames at gmail.com> wrote: > > Hi Larry, > > You're basically there, but you're hitting

Hello Lang, so you are part of the "Jitter-Team"? I'm really interested in this whole jitting-process. I wanted to know, is there a way to load other obj-files, than the one created with clang? Could I load - for example - a obj-File from VisualStudio? Or will the namemangeling fail? Kind regards Björn From: Lang Hames <lhames at gmail.com> To: bjoern.gaier at