The JIT now is more consistent on OSX with the linker-level mangling

OSX (due to legacy to disambigate between asm and C symbols) implements an extra
linker-level mangling which adds another `_` in the name. However, that is only
in the on-disk representation and needs to be dropped upon calling dlsym.

OrcV2 gives us a handle to the symbol with starts with `__` allowing us to
invert the logic of the symbol search where we drop the `__` for dlsym.
This commit is contained in:
Vassil Vassilev 2022-05-16 20:40:52 +00:00 committed by jenkins
parent b7aaa96719
commit b4b96a6d85
2 changed files with 2 additions and 12 deletions

View File

@ -423,17 +423,8 @@ bool IncrementalExecutor::diagnoseUnresolvedSymbols(llvm::StringRef trigger,
<< "Maybe you need to load the corresponding shared library?\n";
}
#ifdef __APPLE__
// The JIT gives us a mangled name which has only one leading underscore on
// all platforms, for instance _ZN8TRandom34RndmEv. However, on OSX the
// linker stores this symbol as __ZN8TRandom34RndmEv (adding an extra _).
assert(!llvm::StringRef(sym).startswith("__") && "Already added!");
std::string libName = m_DyLibManager.searchLibrariesForSymbol('_' + sym,
/*searchSystem=*/ true);
#else
std::string libName = m_DyLibManager.searchLibrariesForSymbol(sym,
/*searchSystem=*/ true);
#endif //__APPLE__
if (!libName.empty())
cling::errs() << "Symbol found in '" << libName << "';"
<< " did you mean to load it with '.L "

View File

@ -74,9 +74,8 @@ public:
// return JD.define(absoluteSymbols(std::move(NewSymbols)));
SymbolNameSet Missing;
for (llvm::orc::SymbolStringPtr Name : Symbols.getSymbolNames())
if (!sys::DynamicLibrary::SearchForAddressOfSymbol((*Name).str()) &&
!m_IncrExecutor.NotifyLazyFunctionCreators((*Name).str()))
Missing.insert(Name);
if (!m_IncrExecutor.NotifyLazyFunctionCreators((*Name).str()))
Missing.insert(Name);
if (!Missing.empty())
return make_error<SymbolsNotFound>(std::move(Missing));