[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:06:32 PST 2017

For the curious: The relocation issue is one of two known incompatibilities
between OrcMCJIT and MCJIT. I'm working on an ORC refactor that should
eliminate both, at which point we can try this out again (with
OrcMCJITReplacement properly #included this time).


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/11344f54/attachment-0001.html>

More information about the lldb-commits mailing list