[orcjit] Using the same name for function name and LLVM module id in LLVM 10

[niyue]

When switching Gandiva from MCJIT to LLJIT [1], I find some test case failed on Ubuntu 20.04 + LLVM 10, after some investigation, I find if LLVM module's ModuleID is the same as the function name created in the module, the LLJIT->lookup API returns an symbol successfully, however the symbol's function address is 0.

Could anyone help to confirm if this is a known issue for LLVM 10 (on Linux)? I did some searching on LLVM bug tracker and github but could not find it.

The minimum test case looks roughly like this:

auto module_ = std::make_unique<llvm::Module>("codegen", *context_); // <== pay special attention to the module id
lljit_ = BuildJIT();
auto buffer = LoadBitcodeFile();
auto src_ir_module = getOwningLazyBitcodeModule(std::move(buffer), *context_);
llvm::Linker::linkModules(*module_, std::move(src_ir_module));

std::string fn_name = "codegen"; // <== use the same name as the llvm::Module above
llvm::Function* fn = llvm::Function::Create(
      prototype, llvm::GlobalValue::ExternalLinkage, fn_name, module_.get());
llvm::orc::ThreadSafeModule tsm(std::move(module_), std::move(context_));
auto error = lljit_->addIRModule(std::move(tsm));

auto sym = lljit_->lookup(fn_name);
if (!sym) { // <== the returned sym has no error
    return Status::CodeGenError("Failed to look up function: " + function +
                            " error: " + llvm::toString(sym.takeError()));
}
auto fn_addr = sym->getAddress(); // <== the fn_addr is 0
auto fn_ptr = reinterpret_cast<FnPtr>(fn_addr); // <== this becomes a nullptr

• the code doesn't work for LLJIT under LLVM 10 + Ubuntu 20.04, but if I change the function name from "codegen" to some different value, the code works
• the similar code (using the same name for LLVM module and function name) works for MCJIT under LLVM 10 + Ubuntu 20.04
• the same code works for LLJIT under LLVM 14 + macOS/Ubuntu 22.04

[1] apache/arrow#39098

[EugeneZelenko]

Could you please try 17 or main branch? Only most recent release is supported.

[llvmbot]

@llvm/issue-subscribers-orcjit

Author: Yue (niyue)

When switching Gandiva from MCJIT to LLJIT [1], I find some test case failed on Ubuntu 20.04 + LLVM 10, after some investigation, I find if LLVM module's ModuleID is the same as the function name created in the module, the `LLJIT->lookup` API returns an symbol successfully, however the symbol's function address is 0.

Could anyone help to confirm if this is a known issue for LLVM 10 (on Linux)? I did some searching on LLVM bug tracker and github but could not find it.

The minimum test case looks roughly like this:

auto module_ = std::make_unique<llvm::Module>("codegen", *context_); // <== pay special attention to the module id
lljit_ = BuildJIT();
auto buffer = LoadBitcodeFile();
auto src_ir_module = getOwningLazyBitcodeModule(std::move(buffer), *context_);
llvm::Linker::linkModules(*module_, std::move(src_ir_module));

std::string fn_name = "codegen"; // <== use the same name as the llvm::Module above
llvm::Function* fn = llvm::Function::Create(
      prototype, llvm::GlobalValue::ExternalLinkage, fn_name, module_.get());
llvm::orc::ThreadSafeModule tsm(std::move(module_), std::move(context_));
auto error = lljit_->addIRModule(std::move(tsm));

auto sym = lljit_->lookup(fn_name);
if (!sym) { // <== the returned sym has no error
    return Status::CodeGenError("Failed to look up function: " + function +
                            " error: " + llvm::toString(sym.takeError()));
}
auto fn_addr = sym->getAddress(); // <== the fn_addr is 0
auto fn_ptr = reinterpret_cast<FnPtr>(fn_addr); // <== this becomes a nullptr

• the code doesn't work for LLJIT under LLVM 10 + Ubuntu 20.04, but if I change the function name from "codegen" to some different value, the code works
• the similar code (using the same name for LLVM module and function name) works for MCJIT under LLVM 10 + Ubuntu 20.04
• the same code works for LLJIT under LLVM 14 + macOS/Ubuntu 22.04

[1] apache/arrow#39098

[niyue]

As I said above, LLVM 14 doesn't run into such an issue, so I assume LLVM 17 is good. I just want to confirm if this is a known issue for LLVM 10