[lldb-dev] [BUG] Many lookup failures

[Greg Clayton via lldb-dev]

So the main question is probably that you have a "CG::Node" and it inherits from one or more other classes and we probably either didn't find definitions for one or more of these classes. I would like to verify this to make sure we understand the problem. Can you do a:

(lldb) image dump -t "CG::Node"

And then see what classes it inherits from by looking at the textual version of the class that gets dumped. And repeat the "image dump -t <typename>" for each class that "CG::Node" inherits from and let me know if any of these classes are empty (no methods or ivars) when they shouldn't be empty? 

The theory behind the compiler debug info reduction that is enabled by default (-flimit-debug-info) is there should be an actual definition of the base classes somewhere and the debugger should be able to find it. We need to determine if this is the case for this binary. There could be an LLDB bug where there is debug info for the base class, but LLDB doesn't find it. The main issue the debugger has with the reduced debug info is we don't currently look across shared library boundaries when creating the type from the debug info. So if you have "CG::Node" in one shared library (liba.so) and it inherits from "Bar" that is in another shared library (libb.so) we will run into this problem as the compiler might emit a forward declaration for "Bar" in the debug info for liba.so. When we debug, we might have the debug info from libb.so or we might not, so even if we are able to fix LLDB to mark classes that it has completed just to keep clang from asserting, we might not be able to fix up the debug info to make it work when debugging later. This is why I prefer to have the information up front even though it might be duplicated elsewhere. There are many valid reasons for reducing the size of debug info: compile times and link timers are shorter, debug info size is smaller, and more.

Greg



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