On Mon, Nov 30, 2015 at 1:57 PM, Eric Christopher <echri...@gmail.com>
wrote:
>
>
> On Mon, 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.
>>
>>
> 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".
>>
>
Why not lookup the definition of B in the debug info at this point rather
than making a stub/empty definition? (& if there is none, then, yes, I
suppose an empty definition of B is as good as anything, maybe - it's going
to produce some weird results, maybe)
> 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.
>>
>
GCC's been doing it for a while longer than Clang & it represents a
substantial space savings in debug info size - it'd be hard to explain to
users why Clang's debug info is so much (20% or more) larger than GCC's
when GCC's contains all the information required and GDB gives a good user
experience with that information and LLDB does not.
> 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
