gamzinav/cling
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

We do not resolve clang/llvm symbols from cling:

Browse Source 
As interpreted user code needs to match their binaries, cling
should find the same symbols as the binaries. This fixes ROOT-10499.
This commit is contained in:
Axel Naumann 2020-08-04 15:40:36 +02:00 committed by jenkins
parent 4b5ad54a0a
commit 2d03378e96
1 changed files with 0 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
lib/Interpreter/IncrementalJIT.cpp
View File

@ -282,22 +282,6 @@ IncrementalJIT::IncrementalJIT(IncrementalExecutor& exe,
m_CompileLayer(m_ObjectLayer, llvm::orc::SimpleCompiler(*m_TM)),
m_LazyEmitLayer(m_CompileLayer) {
// Force the JIT to query for symbols local to itself, i.e. if it resides in a
// shared library it will resolve symbols from there first. This is done to
// implement our proto symbol versioning protection. Namely, if some other
// library provides llvm symbols, we want out JIT to avoid looking at them.
//
// FIXME: In general, this approach causes numerous issues when cling is
// embedded and the framework needs to provide its own set of symbols which
// exist in llvm. Most notably if the framework links against different
// versions of linked against llvm libraries. For instance, if we want to provide
// a custom zlib in the framework the JIT will still resolve to llvm's version
// of libz causing hard-to-debug bugs. In order to work around such cases we
// need to swap the llvm system libraries, which can be tricky for two
// reasons: (a) llvm's cmake doesn't really support it; (b) only works if we
// build llvm from sources.
llvm::sys::DynamicLibrary::SearchOrder
= llvm::sys::DynamicLibrary::SO_LoadedFirst;
// Enable JIT symbol resolution from the binary.
llvm::sys::DynamicLibrary::LoadLibraryPermanently(0, 0);