Brian Kahne via llvm-dev
2017-Sep-22 21:04 UTC
[llvm-dev] Question regarding GlobalMappingLayer in LLVM 5
Hi,
I'm attempting to port some code which uses the GlobalMappingLayer in the
Orc JIT. This code worked fine in LLVM 4, but I'm getting a compile error
with LLVM 5. I think the problem is that this layer hasn't been modified to
account for some of the changes made in LLVM 5, but I wanted to make sure that I
wasn't missing something.
I have code which looks like this:
ModuleHandle addModule(std::unique_ptr<Module> M) {
// Build our symbol resolver:
// Lambda 1: Look back into the JIT itself to find symbols 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 =
OptimizeLayer.findSymbol(Name, false))
return Sym;
return JITSymbol(nullptr);
},
[](const std::string &Name) {
if (auto SymAddr
RTDyldMemoryManager::getSymbolAddressInProcess(Name))
return JITSymbol(SymAddr,
JITSymbolFlags::Exported);
return JITSymbol(nullptr);
});
// Add the set to the JIT with the resolver we created above and a newly
// created SectionMemoryManager.
return OptimizeLayer.addModule(std::move(M),
std::move(Resolver));
}
Where OptimizeLayer is:
IRTransformLayer<GlobalMappingLayerT, OptimizeFunction>
OptimizeLayer;
This worked fine with LLVM 4, but causes a problem in LLVM 5. It looks like the
issue is that IRTransformLayer::addModule returns an Expected<ModuleT>,
whereas GlobalMappingLayer returns just a ModuleHandleT. However, in LLVM 4,
IRTransformLayer::addModuleSet returned a ModuleSetT and
GlobalMappingLayer::addModuleSet also returned a ModuleSetHandleT, so the types
matched up. In LLVM 5, the CompileOnDemandLayer was changed to return an
Expected<ModuleHandleT>, but not GlobalMappingLayer.
Does that explanation seem correct, or am I missing something?
Thx,
-brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170922/a2940730/attachment.html>
Lang Hames via llvm-dev
2017-Sep-28 01:32 UTC
[llvm-dev] Question regarding GlobalMappingLayer in LLVM 5
Hi Brian, Yes - I believe you're correct. I'm working on a fix and extra test coverage now. In the meantime, I believe you should be able to fix the signatures in your copy and everything should "just work". Cheers, Lang. On Fri, Sep 22, 2017 at 2:04 PM, Brian Kahne via llvm-dev < llvm-dev at lists.llvm.org> wrote:> Hi, > > > > I’m attempting to port some code which uses the GlobalMappingLayer in the > Orc JIT. This code worked fine in LLVM 4, but I’m getting a compile error > with LLVM 5. I think the problem is that this layer hasn’t been modified > to account for some of the changes made in LLVM 5, but I wanted to make > sure that I wasn’t missing something. > > > > I have code which looks like this: > > > > ModuleHandle addModule(std::unique_ptr<Module> M) { > > // Build our symbol resolver: > > // Lambda 1: Look back into the JIT itself to find symbols 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 > OptimizeLayer.findSymbol(Name, false)) > > return Sym; > > return JITSymbol(nullptr); > > }, > > [](const std::string &Name) { > > if (auto SymAddr > > RTDyldMemoryManager:: > getSymbolAddressInProcess(Name)) > > return > JITSymbol(SymAddr, JITSymbolFlags::Exported); > > return JITSymbol(nullptr); > > }); > > > > > > // Add the set to the JIT with the resolver we created above and a > newly > > // created SectionMemoryManager. > > return OptimizeLayer.addModule(std::move(M), > > std::move(Resolver)); > > } > > > > Where OptimizeLayer is: > > > > IRTransformLayer<GlobalMappingLayerT, OptimizeFunction> > OptimizeLayer; > > > > This worked fine with LLVM 4, but causes a problem in LLVM 5. It looks > like the issue is that IRTransformLayer::addModule returns an > Expected<ModuleT>, whereas GlobalMappingLayer returns just a > ModuleHandleT. However, in LLVM 4, IRTransformLayer::addModuleSet returned > a ModuleSetT and GlobalMappingLayer::addModuleSet also returned a > ModuleSetHandleT, so the types matched up. In LLVM 5, the > CompileOnDemandLayer was changed to return an Expected<ModuleHandleT>, but > not GlobalMappingLayer. > > > > Does that explanation seem correct, or am I missing something? > > > > Thx, > > > > -brian > > > > > > > > > > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170927/2be17c64/attachment.html>
Lang Hames via llvm-dev
2017-Sep-28 14:56 UTC
[llvm-dev] Question regarding GlobalMappingLayer in LLVM 5
Hi Brian, This has been fixed in r314374. You should be able to apply that patch cleanly to 5.0. Cheers, Lang. On Wed, Sep 27, 2017 at 6:32 PM, Lang Hames <lhames at gmail.com> wrote:> Hi Brian, > > Yes - I believe you're correct. I'm working on a fix and extra test > coverage now. In the meantime, I believe you should be able to fix the > signatures in your copy and everything should "just work". > > Cheers, > Lang. > > On Fri, Sep 22, 2017 at 2:04 PM, Brian Kahne via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Hi, >> >> >> >> I’m attempting to port some code which uses the GlobalMappingLayer in the >> Orc JIT. This code worked fine in LLVM 4, but I’m getting a compile error >> with LLVM 5. I think the problem is that this layer hasn’t been modified >> to account for some of the changes made in LLVM 5, but I wanted to make >> sure that I wasn’t missing something. >> >> >> >> I have code which looks like this: >> >> >> >> ModuleHandle addModule(std::unique_ptr<Module> M) { >> >> // Build our symbol resolver: >> >> // Lambda 1: Look back into the JIT itself to find symbols 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 >> OptimizeLayer.findSymbol(Name, false)) >> >> return Sym; >> >> return JITSymbol(nullptr); >> >> }, >> >> [](const std::string &Name) >> { >> >> if (auto SymAddr >> >> >> RTDyldMemoryManager::getSymbolAddressInProcess(Name)) >> >> return >> JITSymbol(SymAddr, JITSymbolFlags::Exported); >> >> return JITSymbol(nullptr); >> >> }); >> >> >> >> >> >> // Add the set to the JIT with the resolver we created above and >> a newly >> >> // created SectionMemoryManager. >> >> return OptimizeLayer.addModule(std::move(M), >> >> std::move(Resolver)); >> >> } >> >> >> >> Where OptimizeLayer is: >> >> >> >> IRTransformLayer<GlobalMappingLayerT, OptimizeFunction> >> OptimizeLayer; >> >> >> >> This worked fine with LLVM 4, but causes a problem in LLVM 5. It looks >> like the issue is that IRTransformLayer::addModule returns an >> Expected<ModuleT>, whereas GlobalMappingLayer returns just a >> ModuleHandleT. However, in LLVM 4, IRTransformLayer::addModuleSet returned >> a ModuleSetT and GlobalMappingLayer::addModuleSet also returned a >> ModuleSetHandleT, so the types matched up. In LLVM 5, the >> CompileOnDemandLayer was changed to return an Expected<ModuleHandleT>, but >> not GlobalMappingLayer. >> >> >> >> Does that explanation seem correct, or am I missing something? >> >> >> >> Thx, >> >> >> >> -brian >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170928/5ccab0aa/attachment.html>
Reasonably Related Threads
- Question regarding GlobalMappingLayer in LLVM 5
- [cfe-dev] JIT doens't resolve address - Resolve obj-Addresses?
- Possible stack corruption during call to JITSymbol::getAddress()
- Since MCJIT I can't get libm functions to work
- Possible stack corruption during call to JITSymbol::getAddress()