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 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, 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, but not GlobalMappingLayer.

Does that explanation seem correct, or am I missing something?

Thx,

-brian

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.

Hi Brian,

This has been fixed in r314374. You should be able to apply that patch cleanly to 5.0.

Cheers,
Lang.