[lldb-dev] [BUG] Many lookup failures

[Eric Christopher via lldb-dev]

On Mon, Nov 30, 2015 at 9:41 AM Greg Clayton via lldb-dev <
lldb-dev at lists.llvm.org> wrote:

> So be sure to enable -fno-limit-debug-info to make sure the compiler isn't
> emitting lame debug info.
>
>
Greg cannot be more wrong here. There are some limitations to be aware of
when using limit debug info, but if the debug info exists for the type in
the object and debug info then it's the fault of the debugger.  The
limitations are pretty well defined, which is "if you ship the debug info
for all parts of the project you've just built then it should work just
fine". It isn't clear whether or not this is the case here, but the
compiler isn't "emitting lame debug info". (Also, it's not clear which
compiler you're using anyhow so Greg's advice is doubly bad).

-eric




> If things are still failing, check to see what we think "CG::Node"
> contains by dumping the type info for it:
>
> (lldb) image lookup -t CG::Node
>
> This will print out the complete class definition that we have for
> "CG::Node" including ivars and methods. You should be able to see the
> inheritance structure and you might need to also dump the type info for
> each inherited class.
>
> Compilers have been trying to not output a bunch of debug info and in the
> process they started to omit class info for base classes. So if you have:
>
> class A : public B
> {
> };
>
> where class "B" has all sorts of interesting methods, the debug info will
> often look like:
>
> class B; // Forward declaration for class B
>
> class A : public B
> {
> };
>
> When this happens, we must make class A in a clang::ASTContext in
> DWARFASTParserClang and if "B" is a forward declaration, we can't leave it
> as a forward declaration or clang will assert and kill the debugger, so
> currently we just say "oh well, the compiler gave us lame debug info, and
> clang will crash if we don't fix this, so I am going to pretend we have a
> definition for class B and it contains nothing".
>
> I really don't like that the compiler thinks this is OK to do, but that is
> the reality and we have to deal with it.
>
> So the best thing I can offer it you must use -fno-limit-debug-info when
> compiling to stop the compiler from doing this and things should be back to
> normal for you. If this isn't what is happening, let us know what the
> "image lookup -t" output looks like and we can see what we can do.
>
> Greg Clayton
> > On Nov 25, 2015, at 10:00 AM, Ramkumar Ramachandra via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> >
> > Hi,
> >
> > Basic things are failing.
> >
> > (lldb) p lhs
> > (CG::VarExpr *) $0 = 0x000000010d445ca0
> > (lldb) p lhs->rootStmt()
> > (CG::ExprStmt *) $1 = 0x000000010d446290
> > (lldb) p cg_pp_see_it(lhs->rootStmt())
> > (const char *) $2 = 0x000000010d448020 "%A = $3;"
> > (lldb) p cg_pp_see_it(def->rootStmt())
> > error: no member named 'rootStmt' in 'CG::Node'
> > error: 1 errors parsing expression
> > (lldb) p cg_pp_see_it(def)
> > error: no matching function for call to 'cg_pp_see_it'
> > note: candidate function not viable: no known conversion from
> > 'CG::Node *' to 'CG_Obj *' for 1st argument
> > error: 1 errors parsing expression
> >
> > It's total junk; why can't it see the inheritance VarExpr -> Node ->
> > CG_Obj? The worst part is that rootStmt() is a function defined on
> > Node!
> >
> > Ram
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20151130/9f4de19f/attachment.html>