Hi Lang, On Tue, 13 Aug 2019 at 23:26, Lang Hames <lhames at gmail.com> wrote:>> I also get this message: >> JIT session error: Symbols not found: { raise_error } > > > Ahh -- I see the problem. The DynamicLibrarySearchGenerator is using the getAddressOfSymbol method, which (under the hood) is basically issuing an appropriate dlsym lookup, and that does not find explicitly added symbols. To find explicitly added symbols you need to call DynamicLibrary::SearchForAddressOfSymbol instead, but unfortunately that method's behavior is not a good fit for what DynamicLibrarySearchGenerator is trying to do. > > There are two ways you could tackle this: > (1) Write your own generator that calls sys::DynamicLibrary::SearchforAddressOfSymbol, or > (2) Add the symbols up-front using the absoluteSymbols function. > > I would be inclined to do the latter: it's more explicit, and easier to limit searches to exactly the symbols you want. >Okay I will look into this. Thank you for all the help.> > CodeGen optimization seems a more likely culprit: JITTargetMachineBuilder and ExecutionEngineBuilder have different defaults for their CodeGen opt-level. JITTargetMachineBuilder defaults to CodeGenOpt::None, and ExecutionEngineBuilder default to CodeGenOpt::Default. > > > > What happens if you make the following modification to your setup? > > > > auto JTMB = llvm::orc::JITTargetMachineBuilder::detectHost(); > > JTMB->setCodeGenOptLevel(CodeGenOpt::Default); // <-- Explicitly set Codegen opt level > > auto dataLayout = JTMB->getDefaultDataLayoutForTarget(); > > I am not sure what to make of that. What happens if you print TM->getOptLevel() right before running CodeGen? Once your have explicitly set it I would expect them to be the same for ORCv1 and ORCv2. If they're not then it's a plumbing issue. >I explicitly set TM->Options anyway so maybe I don't need this? Regards Dibyendu
On Wed, 14 Aug 2019 at 21:53, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote:> > There are two ways you could tackle this: > > (1) Write your own generator that calls sys::DynamicLibrary::SearchforAddressOfSymbol, or > > (2) Add the symbols up-front using the absoluteSymbols function. > > > > I would be inclined to do the latter: it's more explicit, and easier to limit searches to exactly the symbols you want. > > > > Okay I will look into this. Thank you for all the help. >Looks the documented approach in http://llvm.org/docs/ORCv2.html doesn't work in LLVM 8. Regards
Hi Lang, On Wed, 14 Aug 2019 at 21:53, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote:> > > CodeGen optimization seems a more likely culprit: JITTargetMachineBuilder and ExecutionEngineBuilder have different defaults for their CodeGen opt-level. JITTargetMachineBuilder defaults to CodeGenOpt::None, and ExecutionEngineBuilder default to CodeGenOpt::Default. > > > > > > What happens if you make the following modification to your setup? > > > > > > auto JTMB = llvm::orc::JITTargetMachineBuilder::detectHost(); > > > JTMB->setCodeGenOptLevel(CodeGenOpt::Default); // <-- Explicitly set Codegen opt level > > > auto dataLayout = JTMB->getDefaultDataLayoutForTarget(); > > > > I am not sure what to make of that. What happens if you print TM->getOptLevel() right before running CodeGen? Once your have explicitly set it I would expect them to be the same for ORCv1 and ORCv2. If they're not then it's a plumbing issue. > > > > I explicitly set TM->Options anyway so maybe I don't need this? >I think I finally got ORC v2 working. And I had to set JTMB->setCodeGenOptLevel(CodeGenOpt::Default); I don't quite understand how this interacts with everything else. Regards Dibyendu
Hi Lang,> On Wed, 14 Aug 2019 at 21:53, Dibyendu Majumdar <mobile at majumdar.org.uk> wrote: > > > There are two ways you could tackle this: > > > (1) Write your own generator that calls sys::DynamicLibrary::SearchforAddressOfSymbol, or > > > (2) Add the symbols up-front using the absoluteSymbols function. > > > > > > I would be inclined to do the latter: it's more explicit, and easier to limit searches to exactly the symbols you want. > > > > > > > Okay I will look into this. Thank you for all the help. > > > > Looks the documented approach in http://llvm.org/docs/ORCv2.html > doesn't work in LLVM 8. >Here is what I am ended up doing. auto &JD = ES->getMainJITDylib(); llvm::orc::MangleAndInterner mangle(*ES, *this->DL); llvm::orc::SymbolMap Symbols; for (int i = 0; global_syms[i].name != nullptr; i++) { Symbols.insert( { mangle(global_syms[i].name), llvm::JITEvaluatedSymbol(llvm::pointerToJITTargetAddress(global_syms[i].address), llvm::JITSymbolFlags(llvm::JITSymbolFlags::FlagNames::Exported)) }); } llvm::cantFail(JD.define(llvm::orc::absoluteSymbols(Symbols)), "Failed to install extern symbols"); global_symbols is an array with name and function address. Works on Linux but not on Windows. So I must be missing something else? Thanks and Regards Dibyendu