[Lldb-commits] [lldb] r318039 - Revert "[lldb] Use OrcMCJITReplacement rather than MCJIT as the underlying JIT for LLDB"
Lang Hames via lldb-commits
lldb-commits at lists.llvm.org
Mon Nov 13 10:03:50 PST 2017
Oops -- I thought I'd reverted this ages ago. Evidently not. Thanks Pavel!
On Mon, Nov 13, 2017 at 6:03 AM, Pavel Labath via lldb-commits <
lldb-commits at lists.llvm.org> wrote:
> Author: labath
> Date: Mon Nov 13 06:03:17 2017
> New Revision: 318039
> URL: http://llvm.org/viewvc/llvm-project?rev=318039&view=rev
> 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.
> Modified: lldb/trunk/source/Expression/IRExecutionUnit.cpp
> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/
> --- lldb/trunk/source/Expression/IRExecutionUnit.cpp (original)
> +++ lldb/trunk/source/Expression/IRExecutionUnit.cpp Mon Nov 13 06:03:17
> @@ -277,8 +277,7 @@ void IRExecutionUnit::GetRunnableInfo(St
> std::unique_ptr<MemoryManager>(new MemoryManager(*this)))
> - .setOptLevel(llvm::CodeGenOpt::Less)
> - .setUseOrcMCJITReplacement(true);
> + .setOptLevel(llvm::CodeGenOpt::Less);
> llvm::StringRef mArch;
> llvm::StringRef mCPU;
> lldb-commits mailing list
> lldb-commits at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-commits