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@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@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits >
_______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
