[lldb-dev] [BUG] Many lookup failures

[Greg Clayton via lldb-dev]

> On Nov 30, 2015, at 1:57 PM, Eric Christopher <echristo at gmail.com> wrote:
> 
> 
> 
> 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.  

This is true and what we are going to determine. My follow up emails has instructions to help us determine this.

> 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).

I shouldn't have said "lame", sorry for that. We do need to determine the root cause of this, so hopefully we can find out what the main issue is, again, see my follow up email that preceded this email.

LLDB can start marking up classes that it completes just to keep clang from asserting (we do this for base classes that are forward declarations and for member variable that are structs/classes whose type is a forward declaration) in a way such that when we copy the type from one AST to another we can possibly find the real version of the type from the other shared library and use the real definition. This does mean if you have debug info for one shared library but not the other we will still have reduced debugging abilities. 

On MacOSX, we don't enable -flimit-debug-info by default so we tend not to run into this issue as we don't require people to have debug info for everything in order to debug as kernel debugging is very affected by this on darwin. All other platforms have it on by default.

> 
> -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