search for: findsymbol

Displaying 20 results from an estimated 75 matches for "findsymbol".

2016 Apr 01
2
Kaleidoscope on Windows - bug maybe found?
To try to find out why it was crashing, I followed the trail of function calls: C:\llvm\examples\Kaleidoscope\Orc\initial\toy.cpp auto ExprSymbol = J.findUnmangledSymbol("__anon_expr"); JITSymbol findUnmangledSymbol(const std::string Name) { return findSymbol(mangle(Name)); } JITSymbol findSymbol(const std::string &Name) { return CompileLayer.findSymbol(Name, true); } CompileLayerT CompileLayer; typedef IRCompileLayer<ObjLayerT> CompileLayerT; C:\llvm\include\llvm\ExecutionEngine\Orc\IRCompileLayer.h template <typename Bas...
2016 Apr 01
0
Kaleidoscope on Windows - bug maybe found?
Addendum: this still fails: auto ExprSymbol = J.findSymbol("putchard"); As yet, I have no idea why - that symbol even seemed to be exported: extern "C" double putchard(double X) { putchar((char)X); return 0; } On Fri, Apr 1, 2016 at 2:42 AM, Russell Wallace <russell.wallace at gmail.com> wrote: > To try to find out wh...
2017 Jul 27
2
llvm 5.0 release rc1 : ExecutionEngine fatal error on MCJIT::getFunctionAddress
...ddress) when the symbol is not found : *uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool CheckFunctionsOnly) { std::string MangledName; { raw_string_ostream MangledNameStream(MangledName); Mangler::getNameWithPrefix(MangledNameStream, Name, getDataLayout()); } return findSymbol(MangledName, CheckFunctionsOnly).getAddress();}* Now with the current implementation (llvm 5.0 rc1 tag) : *uint64_t MCJIT::getSymbolAddress(const std::string &Name, bool CheckFunctionsOnly) { std::string MangledName; { raw_string_ostream MangledNameStream(MangledName); M...
2017 May 07
2
[cfe-dev] JIT doens't resolve address - Resolve obj-Addresses?
...by the JITSymbolResolver that > is created by createLambdaResolver. In your example the resolution process > is two-step: First the JIT searches its own function definitions to see if > there is a function called "printf" defined there (this is what the call to > CompileLayer.findSymbol does): > > [&](const std::string &Name) { > printf("FLUSH :0\n"); > if (auto Sym = CompileLayer.findSymbol(Name, false)) > return Sym; > return JITSymbol(nullptr); > } > > Then, if it doesn't find a definition there, it falls back to searc...
2019 Sep 16
2
Orc JIT vs. implicit template instanciation in LLVM 8
...effort. ORCv2's solution to these > problems is much more robust, but required fundamentally changing the > resolution model (i.e. introducing the idea of responsibility sets), which > may have shaken loose other bugs in ORCv1/Legacy handling of these symbols. > > The problem is, findSymbol() returns a null JITSymbol (address 0) if the >> symbol has not been materialized yet. And naturally it hasn't, since we are >> trying to determine which symbols need to be materialized... > > > If Finalized == false, then we should be hitting this: > > if (!Finaliz...
2019 Sep 16
2
Orc JIT vs. implicit template instanciation in LLVM 8
...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 LegacyRTDyldObjectLink...
2016 May 24
2
ORC and MCJIT clients: Heads up, API breaking changes in the pipeline.
...but are unlikely to. Where they do the fixes are likely to be trivial. ORC clients will be affected, but the fixes should also be straightforward. I have three upcoming changes in mind: 1) RuntimeDyld (the linker underlying MCJIT and ORC) will now search for symbols using the SymbolResolver's findSymbolInLogicalDylib first, before falling back to the findSymbol method if findSymbolInLogicalDylib returns a null result. This is a step towards making RuntimeDyld behave more like a static linker: we prefer to link against symbols defined in the same "logical dylib" as the module being JIT...
2016 Jul 07
2
ObjectCache and getFunctionAddress issue
Hi all, I'm trying to add pre-compiled object cache to my run-time. I've implemented the object cache as follow: class EngineObjectCache : public llvm::ObjectCache { private: std::unordered_map<std::string, std::unique_ptr<llvm::MemoryBuffer>> CachedObjs; public: virtual void notifyObjectCompiled(const llvm::Module *M, llvm::MemoryBufferRef Obj) { auto id =
2015 Jun 24
3
[LLVMdev] ORC and relocations
...s 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 accordingly. Would this be a reasonable approach? Thanks, Eugene -------------- next part -------------- An HTML attachment was scrubbed... URL: <h...
2017 Apr 09
2
Possible stack corruption during call to JITSymbol::getAddress()
...ymbols that are part of // the same "logical dylib". // Lambda 2: Search for external symbols in the host process. auto Resolver = createLambdaResolver( [&](const std::string &Name) { if (auto Sym = CompileLayer.findSymbol(Name, false)) return Sym; return JITSymbol(nullptr); }, [](const std::string &Name) { if (auto SymAddr = RTDyldMemoryManager::getSymbolAddressInProcess(Name)) return JITSymbo...
2015 Jun 26
2
[LLVMdev] ORC and relocations
...onList(Relocs, 0); } else { uint64_t Addr = 0; RTDyldSymbolTable::const_iterator Loc = GlobalSymbolTable.find(Name); if (Loc == GlobalSymbolTable.end()) { // This is an external symbol, try to get its address from the symbol // resolver. Addr = Resolver.findSymbol(Name.data()).getAddress(); // The call to getSymbolAddress may have caused additional modules to // be loaded, which may have added new entries to the // ExternalSymbolRelocations map. Consquently, we need to update our // iterator. This is also why retrieval of th...
2016 May 27
1
ORC and MCJIT clients: Heads up, API breaking changes in the pipeline.
...o the fixes are > likely to be trivial. ORC clients will be affected, but the fixes > should also be straightforward. > > I have three upcoming changes in mind: > > 1) RuntimeDyld (the linker underlying MCJIT and ORC) will now search > for symbols using the SymbolResolver's findSymbolInLogicalDylib first, > before falling back to the findSymbol method if > findSymbolInLogicalDylib returns a null result. > > This is a step towards making RuntimeDyld behave more like a static > linker: we prefer to link against symbols defined in the same "logical > dylib&qu...
2017 Apr 17
2
Possible stack corruption during call to JITSymbol::getAddress()
...the same "logical dylib". >> // Lambda 2: Search for external symbols in the host process. >> auto Resolver = createLambdaResolver( >> [&](const std::string &Name) { >> if (auto Sym = CompileLayer.findSymbol(Name, false)) >> return Sym; >> return JITSymbol(nullptr); >> }, >> [](const std::string &Name) { >> if (auto SymAddr = >> RTDyldMemory...
2017 Apr 20
2
Possible stack corruption during call to JITSymbol::getAddress()
...dylib". >>>> // Lambda 2: Search for external symbols in the host process. >>>> auto Resolver = createLambdaResolver( >>>> [&](const std::string &Name) { >>>> if (auto Sym = CompileLayer.findSymbol(Name, false)) >>>> return Sym; >>>> return JITSymbol(nullptr); >>>> }, >>>> [](const std::string &Name) { >>>> if (auto SymAddr = >>&...
2015 Mar 13
4
[LLVMdev] Thoughts about ExecutionEngine/MCJIT interface
Hi, I think ExecutionEngine as a common interface for both Interpreter and MCJIT is almost useless in the current form. There are separated methods in ExecutionEngine for similar or the same features provided by Interpreter and MCJIT, i.e. to get a pointer to function you should call getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT. Personally, I'm using MCJIT and
2015 Jun 30
2
[LLVMdev] ORC and relocations
...onList(Relocs, 0); } else { uint64_t Addr = 0; RTDyldSymbolTable::const_iterator Loc = GlobalSymbolTable.find(Name); if (Loc == GlobalSymbolTable.end()) { // This is an external symbol, try to get its address from the symbol // resolver. Addr = Resolver.findSymbol(Name.data()).getAddress(); // The call to getSymbolAddress may have caused additional modules to // be loaded, which may have added new entries to the // ExternalSymbolRelocations map. Consquently, we need to update our // iterator. This is also why retrieval of th...
2017 Sep 25
1
Some questions regarding ORC JIT apis
Hi Dibyendu > On Windows 10 64-bit, with > dynamic linking - I found one unexpected behaviour - the findSymbol() > is unable to locate the JIT compiled function in the module if search > for "exported" only is true ... even though the function is defined as > having ExternalLinkage. I have to test on Linux / Mac OSX to see if > the behaviour is different there. Correct. There's a c...
2017 May 01
1
Possible stack corruption during call to JITSymbol::getAddress()
...;> // Lambda 2: Search for external symbols in the host process. >>>>>> auto Resolver = createLambdaResolver( >>>>>> [&](const std::string &Name) { >>>>>> if (auto Sym = CompileLayer.findSymbol(Name, >>>>>> false)) >>>>>> return Sym; >>>>>> return JITSymbol(nullptr); >>>>>> }, >>>>>> [](const std::string &Name) { >>...
2016 May 17
3
External function resolution: MCJIT vs ORC JIT
...gt;getFunction ("sqr"), a); builder.CreateRet (asq); // Set up compilation if (orc) { auto Resolver = llvm::orc::createLambdaResolver( // External lookup functor [&](const std::string &name) { if (auto Sym = Compilelayer.findSymbol(name, true)) return llvm::RuntimeDyld::SymbolInfo(Sym.getAddress(), Sym.getFlags()); // If not found as a symbol, look up in current process. // Why doesn't this work? if (auto Addr = llvm::RTDyldMemoryManager::getSymbolAddress...
2016 May 19
2
External function resolution: MCJIT vs ORC JIT
...t; builder.CreateRet (asq); > > // Set up compilation > if (orc) { > auto Resolver = llvm::orc::createLambdaResolver( > // External lookup functor > [&](const std::string &name) { > if (auto Sym = Compilelayer.findSymbol(name, true)) > return llvm::RuntimeDyld::SymbolInfo(Sym.getAddress(), Sym.getFlags()); > // If not found as a symbol, look up in current process. > // Why doesn't this work? > if (auto Addr = llvm::RTDyldMemoryManag...