aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorTom Stellard <tstellar@redhat.com>2017-11-22 16:57:36 +0000
committerTom Stellard <tstellar@redhat.com>2017-11-22 16:57:36 +0000
commitf0cacaaac7686f81c9ea4d0040f2c68c371a1f7a (patch)
tree3cc6aa0ab40c7b977176be5e10c0bb15620366d3
parent1d4523196295fa64f40580e18601235246ba1f60 (diff)
downloadllvm-f0cacaaac7686f81c9ea4d0040f2c68c371a1f7a.zip
llvm-f0cacaaac7686f81c9ea4d0040f2c68c371a1f7a.tar.gz
llvm-f0cacaaac7686f81c9ea4d0040f2c68c371a1f7a.tar.bz2
Merging r318039:
------------------------------------------------------------------------ r318039 | labath | 2017-11-13 06:03:17 -0800 (Mon, 13 Nov 2017) | 37 lines Revert "[lldb] Use OrcMCJITReplacement rather than MCJIT as the underlying JIT for LLDB" This commit really did not introduce any functional changes (for most people) but it turns out it's not for the reason we thought it was. The reason wasn't that Orc is a perfect drop-in replacement for MCJIT, but it was because we were never using Orc in the first place, as it was not initialized. Orc's initialization relies on a global constructor in the LLVMOrcJIT.a. Since this archive does not expose any symbols referenced from other object files, it does not get linked into liblldb when linking against llvm components statically. However, in an LLVM_LINK_LLVM_DYLIB=On build, LLVMOrcJit.a is linked into libLLVM.so using --whole-archive, so the global constructor does end up firing. The result of using Orc jit is pr34194, where lldb fails to evaluate even very simple expressions. This bug can be reproduced in non-LLVM_LINK_LLVM_DYLIB builds by making sure Orc jit is linked into liblldb, for example by #including llvm/ExecutionEngine/OrcMCJITReplacement.h in IRExecutionUnit.cpp (and adding OrcJIT as a dependency to the relevant CMakeLists.txt file). The bug reproduces (at least) on linux and osx. The root cause of the bug seems to be related to relocation processing. It seems Orc processes relocations earlier than the system it is replacing. This means the relocation processing happens before we have had a chance to remap section load addresses to reflect their address in the target process memory, so they end up pointing to locations in the lldb's address space instead. I am not sure whether this is a bug in Orc jit, or in how we are using it from lldb, but in any case it is preventing us from using Orc right now. Reverting this fixes LLVM_LINK_LLVM_DYLIB build, and makes it clear that we are in fact *not* using Orc, and we never really were. This reverts commit r279327. ------------------------------------------------------------------------ llvm-svn: 318845
-rw-r--r--lldb/source/Expression/IRExecutionUnit.cpp3
1 files changed, 1 insertions, 2 deletions
diff --git a/lldb/source/Expression/IRExecutionUnit.cpp b/lldb/source/Expression/IRExecutionUnit.cpp
index e31483f..363e6fe 100644
--- a/lldb/source/Expression/IRExecutionUnit.cpp
+++ b/lldb/source/Expression/IRExecutionUnit.cpp
@@ -282,8 +282,7 @@ void IRExecutionUnit::GetRunnableInfo(Status &error, lldb::addr_t &func_addr,
.setMCJITMemoryManager(
std::unique_ptr<MemoryManager>(new MemoryManager(*this)))
.setCodeModel(codeModel)
- .setOptLevel(llvm::CodeGenOpt::Less)
- .setUseOrcMCJITReplacement(true);
+ .setOptLevel(llvm::CodeGenOpt::Less);
llvm::StringRef mArch;
llvm::StringRef mCPU;