On Tue, Jul 22, 2014 at 2:52 PM, Reid Kleckner <[email protected]> wrote:
> This sounds like it might be a symptom of the -fstandalone-debug-info > issue. There was some recent discussion on lldb-dev about it and in the > past on cfe-dev. > Yep. I thought it might be, but (as I read that initial discussion) it sounded like building chrome with -fstandalone-debug wasn't a great idea because it would blow out the linker. So I figured I'd dive in and try and understand the problem in more detail and maybe fix it. > First, are you building Chromium with Clang? > > If you are, can you rebuild Chromium (or just the TU that has A's debug > info) with -fstandalone-debug-info and still reproduce the problem? > Yes, and no. So it is -fstandalone-debug related. I'll respond on Greg's response with more questions; I'd like to understand what would be required to fix this properly, and if it looks tractable, maybe take it on. (From a naive, debug user perspective, it was really easy to run into debugging chrome.) -- Randy > > If so, we should still try to fix this in LLDB. It mostly just narrows > down what kind of problem this is. > > > On Tue, Jul 22, 2014 at 11:41 AM, Randy Smith <[email protected]> > wrote: > >> >> I'm chasing a crash in lldb, and my current "that doesn't seem right" has >> to do with a conflict between a decl and its origin decl (the >> transformation done at the beginning of >> tools/lldb/source/Expression/ClangASTSource.cpp:ClangASTSource::layoutRecordType()). >> So I'm trying to understand how decls and origin decls get setup during >> the symbol import process. Can anyone give me a sketch/hand? Specific >> questions include: >> * There are multiple ASTContexts involved (e.g. the src and dst contexts >> in the signature of >> tools/lldb/source/Symbol/ClangASTImporter.cpp:ClangASTImporter::CopyType); >> do those map to compilation units, or to shared library modules? Is there >> a simple way to tell what CU/.so an ASTContext maps to? >> * Does a decl always have an origin decl, even if it was loaded from an >> ASTContext (?) that has a complete definition? >> * When an origin decl is looked up, should all the types in it be >> completed, or might it have incomplete types? It seems as if there is code >> assuming that these types will always be complete. >> >> Context (warning, gets detailed, possibly with irrelevant details because >> newbie): lldb is crashing in clang::ASTContext::getASTRecordLayout with the >> assertion "Cannot get layout of forward declarations!". The type in >> question is an incomplete type (string16, aka. basic_string<unsigned short, >> ...>). Normally clang::ASTContext::getASTRecordLayout() would call >> getExternalSource()->CompleteType() to complete the type, but in this case >> it isn't because the type is marked as !hasExternalLexicalStorage(). >> >> The *weird* thing is that the type has previously been completed, further >> up the stack, but in a different AST node (same name). In more detail: >> Class A contains an instance of class B contains an instance of class C >> (==string16). I'm seeing getASTRecordLayout called on class A, which then >> calls it (indirectly, though the EmptySubobjectMap construtor) on class B, >> which then calls it (ditto) on class C (all works). Then the stack unwinds >> up to the B call, which proceeds to the Builder.Layout() line in that >> function. It ends up (through the transformation mentioned above in >> clang::ClangASTSource::LayoutRecordType()) calling getASTRecordLayout() on >> the origin decl. When it recurses down to class C, that node isn't >> complete, isn't completed, and causes an assertion. So I'm trying to >> figure out whether the problem is that any decl hanging off an origin_decl >> should be complete, or that that node shouldn't be marked as >> !hasExternalLexicalStorage(). (Or something else; I've already gone >> through several twists and turns debugging this problem :-}.) >> >> The crash is reproducible, but one of the reproduction steps is "Build >> chrome", so I figured I'd work on it some myself to teach myself lldb >> rather than try to file a bug on it. The wisdom of that choice in >> question :-}. >> >> Any thoughts anyone has would be welcome. >> >> -- Randy >> >> >> _______________________________________________ >> lldb-dev mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev >> >> >
_______________________________________________ lldb-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
