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

LLVM 5.0 comes with special library lookup ordering options.

Browse Source 
Force using the old behavior and explain why it is not so good idea.
This commit is contained in:
Vassil Vassilev 2017-10-21 19:02:49 +02:00 committed by sftnight
parent d6fe62edaf
commit 985b2c8740
1 changed files with 16 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
lib/Interpreter/IncrementalJIT.cpp
View File

@ -282,6 +282,22 @@ 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);