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@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@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@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
