Daniel,
On May 29, 2013, at 2:09 PM, "Malea, Daniel" <[email protected]> wrote:
> I have just started looking into a problem that's happening with the Debian
> test runs (but interestingly not under manual configure/cmake builds) where
> the LLVMContext is coming up as uninitialized, thereby causing the internal
> LLDB segfault in the following stack trace. Any hints where I should start
> digging for the root-cause? I imagine LLDB attempts to use a global
> LLVMContext (?), but I have not yet found the code that initializes it...
Each ClangExpressionParser sets up its own LLVMContext. See
ClangExpressionParser.cpp:376 or thereabouts. The LLVMContext is then
installed into the Clang code generator, but we retain ownership.
> Program received signal SIGSEGV, Segmentation fault.
> llvm::Value::getContext (this=0x10ea950) at
> /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/lib/IR/Value.cpp:480
> 480 LLVMContext &Value::getContext() const { return VTy->getContext(); }
> (gdb) bt
> #0 llvm::Value::getContext (this=0x10ea950) at
> /home/daniel/dev/llvm-toolchain-snapshots-automake/llvm-toolchain-snapshot-3.4~svn182852/lib/IR/Value.cpp:480
If you’re dying in llvm::Value::getContext, it doesn’t sound to me like the
context is bad, it’s VTy that’s bad.
You’re in the code that prepares LLVM IR for running in the target.
ResolveFunctionPointers changes by-name function references to literals cast to
function pointers – essentially we’re pre-linking the code because we don’t
trust the MCJIT to do so. RegisterFunctionMetadata attaches a little bit of
metadata to each call to the function, letting later passes (in particular, the
Objective-C checkers) know what the name of the called function is.
Hope this helps, and happy debugging.
Sean_______________________________________________
lldb-dev mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
