>
> 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)
LLDB creates types using only the debug info from the currently shared library
and we don't take a copy of a type from another shared library when creating
the types for a given shared library. Why? LLDB has a global repository of
modules (the class that represents an executable or shared library in LLDB). If
Xcode, or any other IDE that can debug more that one thing at a time has two
targets: "a.out" and "b.out", they share all of the shared library modules so
that if debug info has already been parsed in the target for "a.out" for the
shared library "liba.so" (or any other shared library), then the "b.out" target
has the debug info already loaded for "liba.so" because "a.out" already loaded
that module (LLDB runs in the same address space as our IDE). This means that
all debug info in LLDB currently creates types using only the info in the
current shared library. When we debug "a.out" again, we might have recompiled
"liba.so", but not "libb.so" and when we debug again, we don't need to reload
the debug info for "libb.so" if it hasn't changed, we just reload "liba.so" and
its debug info. When we rerun a target (run a.out again), we don't need to
spend any time reloading any shared libraries that haven't changed since they
are still in our global shared library cache. So to keep this global library
cache clean, we don't allow types from another shared library (libb.so) to be
loaded into another (liba.so), otherwise we wouldn't be able to reap the
benefits of our shared library cache as we would always need to reload debug
info every time we run.
LLDB does have the ability, when displaying types, to grab types from the best
source (other shared libraries), we just don't transplant types in the LLDB
shared library objects (lldb_private::Module) versions of the types. We do
currently assume that all classes that aren't pointers or references (or other
types that can legally have forward declarations of structs or classes) are
complete in our current model.
There are modifications we can do to LLDB to deal with the partial debug info
and possible lack thereof when the debug info for other shared libraries are
not present, but we haven't done this yet in LLDB.
>
> 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.
LLDB currently recreates types in a clang::ASTContext and this imposes much
stricter rules on how we represent types which is one of the weaknesses of the
LLDB approach to type representation as the clang codebase often asserts when
it is not happy with how things are represented. This does payoff IMHO in the
complex expressions we can evaluate where we can use flow control, define and
use C++ lambdas, and write more than one statement when writing expressions.
But it is definitely a tradeoff. GDB has its own custom type representation
which can be better for dealing with the different kinds and completeness of
debug info, but I am comfortable with our approach.
So we need to figure out what the root problem is here before we can go further
and talk about any additional solutions or fixes that may be required.
Greg
>
> 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
