> On Sep 13, 2015, at 4:26 PM, carr27 via lldb-dev <lldb-dev@lists.llvm.org>
> wrote:
>
> Hello,
>
> I'm working on an LLVM pass that I'm trying to debug it with LLDB, but I'm
> running into a few problems. I'm generally following this turtorial [1] but
> I run my pass with opt instead from inside clang. So I run:
>
> $ lldb ../build/bin/opt
> (lldb) break set --name MyPass::runOnModule
> (lldb) run -load ../build/lib/LLVMMyPass.so -MyPass test.ll
>
> My runOnModule is just:
>
> bool MyPass::runOnModule(Module &M) {
> for (auto& F : M) {
> for (auto& BB : F) {
> for (auto& I : BB) {
> I.dump(); // step to here
> }
> }
> }
> }
>
> It hits the breakpoint correctly then I single step into the inner most loop.
> Then I try the following LLDB commands:
>
> "e I.dump()" gives me what I expect (it prints the LLVM instruction).
>
> "e BB.dump()" gives me:
> error: no member named 'dump' in 'llvm::BasicBlock'
> error: 1 errors parsing expression
>
> ...but llvm::BasicBlock definitely does have a member named dump.
>
We would need to look at what LLDB thinks the llvm::BasicBlock type looks like.
What does LLDB say in response to:
(lldb) image lookup -t llvm::BasicBlock
You may be running into a case where the debug info only has a forward
declaration to llvm::BasicBlock... Let me know what the output of the above
command looks like. The other thing is there is a lot of space savings that get
enabled by default that omits important debug info where definitions of classes
will be omitted from the debug info if they aren't directly used in the current
source files. So it also depends on the debug info. If you have an ELF file for
clang that you can make available, I can take a look and see what I can see.
> "e M.dump()" gives me:
> lldb:
> /home/carr27/dataconf-workspace2/llvm/tools/clang/lib/AST/RecordLayoutBuilder.cpp:2883:
> const clang::ASTRecordLayout &clang::ASTContext::getASTRecordLayout(const
> clang::RecordDecl *) const: Assertion `D && "Cannot get layout of forward
> declarations!"' failed.
> ./lldb.sh: line 1: 6736 Aborted (core dumped)
Sounds like we are trying to complete a forward declaration and things go bad.
One of the drawbacks in llvm and clang and that the library likes to assert
when it is unhappy. This is fine for development, but when you ship a debugger
that uses clang, we don't want it asserting and killing the debugger.
>
> I don't know exactly what is going on, but it seems like LLDB doesn't know
> about some of the LLVM classes. Can anyone give me a pointer as to what
> might be wrong?
A few things can be going on:
1 - You are using the 3.6 release which is not good enough for debugging on
linux. You will need to use the 3.7 release or preferably the top of tree SVN
for llvm/clang/LLDB.
2 - The compiler that is compiling llvm/clang is pulling tricks and not
emitting all of the debug info you need. clang has many optimizations that try
to limit the amount of debug info that it emits and it often will omit base
class definitions and many other things. There is an option that you can modify
your build to pass if you are building with clang: -fstandalone-debug. This
will ensure that debug info isn't emitted partially when it would affect the
ability of a debugger to reconstruct a type from the debug info.
Let me know what your "llvm::BasicBlock" looks like and which of the above
cases you think you might be running into.
Greg
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
