[lldb-dev] Trying to understand symbol importing and its relationship to ASTs

[Randy Smith]

On Tue, Jul 22, 2014 at 2:52 PM, Reid Kleckner <rnk at google.com> 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 <rdsmith at chromium.org>
> 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
>> lldb-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20140722/ff485a50/attachment.html>