search for: jitsymbol

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

...ll Wallace <russell.wallace at gmail.com> wrote: > 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<Obj...

...tion--feel free to point me in the correct direction. I could be doing something wrong here but stackoverflow didn't feel like the correct place for this since there's so little there about LLVM ORC. Basically, I have a reproduction case (below) where if I throw an exception before I call JITSymbol::getAddress() everything works properly but throwing the same exception afterward will result in a SIGSEGV during stack unwinding. This suggests to me that somehow the stack is getting corrupted during the JITSymbol::getAddress() call. This problem was initially discovered while working on my own...

...ial:       auto Resolver = llvm::orc::createLambdaResolver(                               [&](const std::string &Name) {                             if (auto Sym = CompileLayer.findSymbol(Name, false))                               return Sym;                             return llvm::JITSymbol(nullptr);                               },                               [](const std::string &Name) {                             if (auto SymAddr = llvm::RTDyldMemoryManager::getSymbolAddressInProcess(Name))                               return llvm::JITSymbol(SymAddr, llvm::JITSymbolFla...

...irection. I could be doing >> something wrong here but stackoverflow didn't feel like the correct place >> for this since there's so little there about LLVM ORC. >> >> Basically, I have a reproduction case (below) where if I throw an >> exception before I call JITSymbol::getAddress() everything works properly >> but throwing the same exception afterward will result in a SIGSEGV during >> stack unwinding. This suggests to me that somehow the stack is getting >> corrupted during the JITSymbol::getAddress() call. >> >> This problem was...

...[&](const std::string &Name) { if (auto Sym = OptimizeLayer.findSymbol(Name, false)) return Sym; return JITSymbol(nullptr); }, [](const std::string &Name) { if (auto SymAddr = RTDyldMemoryManager::getSymbolAddressInProces...

...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 (!Finalized) > return JITSymb...

...> something wrong here but stackoverflow didn't feel like the correct place >>>> for this since there's so little there about LLVM ORC. >>>> >>>> Basically, I have a reproduction case (below) where if I throw an >>>> exception before I call JITSymbol::getAddress() everything works properly >>>> but throwing the same exception afterward will result in a SIGSEGV during >>>> stack unwinding. This suggests to me that somehow the stack is getting >>>> corrupted during the JITSymbol::getAddress() call. >>&gt...

...egacy 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 LegacyRTDyldObjectLinkingLayer::findSymbol(). 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... My quick fix is to change these lines in LegacyRTDyldObjectLinkingLayerBase::LinkedObject::getSymbol(): if (!Finalized) ret...

...ackoverflow didn't feel like the correct place >>>>>> for this since there's so little there about LLVM ORC. >>>>>> >>>>>> Basically, I have a reproduction case (below) where if I throw an >>>>>> exception before I call JITSymbol::getAddress() everything works properly >>>>>> but throwing the same exception afterward will result in a SIGSEGV during >>>>>> stack unwinding. This suggests to me that somehow the stack is getting >>>>>> corrupted during the JITSymbol::getAdd...

...; references with own addresses? Like when somebody used printf in the > generated obj-File, but I replace the address with my own printf? > > You can load precompiled object files by calling addObjectSet on the > ObjectLayer. > > All external symbol references are resolved 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):...

...orc::createLambdaResolver( >> [&](const std::string &Name) { >> if (auto Sym = CompileLayer.findSymbol(Name, false)) >> return Sym; >> return llvm::JITSymbol(nullptr); >> }, >> [](const std::string &Name) { >> if (auto SymAddr = >> llvm::RTDyldMemoryManager::getSymbolAddressInProcess(Name)) >> return...

...[&](const std::string &Name) > { > > if (auto Sym = > OptimizeLayer.findSymbol(Name, false)) > > return Sym; > > return JITSymbol(nullptr); > > }, > > [](const std::string &Name) { > > if (auto SymAddr = > > RTDyl...

...nds up in my application where 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 particula...

...tion where 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 i...

...79:40: >  required from here > /home/davidbolvansky/trunk/llvm/include/llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:314:29: > warning: redundant move in return statement [-Wredundant-move] > 314 |         return std::move(Err); Note that the move (into the implicit JITSymbol(Error) ctor) is only redundant if the compiler implements a fix for <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579> "Return by converting move constructor". (But not sure whether the LLVM compiler baselines imply that, anyway. In LibreOffice it forced me to...

...; >> /home/davidbolvansky/trunk/llvm/include/llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:314:29: >> > warning: redundant move in return statement [-Wredundant-move] >> > 314 | return std::move(Err); >> >> Note that the move (into the implicit JITSymbol(Error) ctor) is only >> redundant if the compiler implements a fix for >> <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579> >> "Return by converting move constructor". (But not sure whether the LLVM >> compiler baselines imply that, anyway....

...TDyldObjectLinkingLayer: error: too many template arguments for class template 'IRCompileLayer' IRCompileLayer CompileLayer; |#define_CONTRIB_JIT_ 1#include"llvm/ADT/STLExtras.h"#include"llvm/ExecutionEngine/ExecutionEngine.h"#include"llvm/ExecutionEngine/JITSymbol.h"#include"llvm/ExecutionEngine/RTDyldMemoryManager.h"#include"llvm/ExecutionEngine/SectionMemoryManager.h"#include"llvm/ExecutionEngine/Orc/CompileUtils.h"#include"llvm/ExecutionEngine/Orc/IRCompileLayer.h"#include"llvm/ExecutionEngine/Orc/LambdaRe...

...+ return 0; + } + else + return FnBodyAddr; + } + } + return 0; + } + +private: diff --git a/LogicalDylib.h b/LogicalDylib.h index 84e3bf5..2e35cfd 100644 --- a/LogicalDylib.h +++ b/LogicalDylib.h @@ -17,6 +17,8 @@ #include "JITSymbol.h" #include <string> #include <vector> +#include "llvm/IR/Mangler.h" +#include "llvm/Support/raw_ostream.h" namespace llvm { namespace orc { @@ -77,6 +79,24 @@ public: return LMH->Resources; } + static std::string mangle(StringRef Name, const D...

.../trunk/llvm/include/llvm/ExecutionEngine/Orc/CompileOnDemandLayer.h:314:29: >>>> > warning: redundant move in return statement [-Wredundant-move] >>>> > 314 | return std::move(Err); >>>> >>>> Note that the move (into the implicit JITSymbol(Error) ctor) is only >>>> redundant if the compiler implements a fix for >>>> <http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579> >>>> "Return by converting move constructor". (But not sure whether the >>>> LLVM >&g...