[Lldb-commits] [lldb] r318039 - Revert "[lldb] Use OrcMCJITReplacement rather than MCJIT as the underlying JIT for LLDB"

[Lang Hames via lldb-commits]

Oops -- I thought I'd reverted this ages ago. Evidently not. Thanks Pavel!

-- Lang.

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
> Log:
> 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
>
> Modified: lldb/trunk/source/Expression/IRExecutionUnit.cpp
> URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/
> Expression/IRExecutionUnit.cpp?rev=318039&r1=318038&r2=318039&view=diff
> ============================================================
> ==================
> --- lldb/trunk/source/Expression/IRExecutionUnit.cpp (original)
> +++ lldb/trunk/source/Expression/IRExecutionUnit.cpp Mon Nov 13 06:03:17
> 2017
> @@ -277,8 +277,7 @@ void IRExecutionUnit::GetRunnableInfo(St
>        .setRelocationModel(relocModel)
>        .setMCJITMemoryManager(
>            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
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20171113/6dece29d/attachment.html>