<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jul 22, 2014 at 2:52 PM, Reid Kleckner <span dir="ltr"><<a href="mailto:rnk@google.com" target="_blank" class="cremed">rnk@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.</div>
</blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>First, are you building Chromium with Clang?<br></div>
<div><br></div><div>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?</div></div></blockquote><div><br></div><div>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.)</div>
<div><br></div><div>-- Randy</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>If so, we should still try to fix this in LLDB. It mostly just narrows down what kind of problem this is.</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div><div class="h5">On Tue, Jul 22, 2014 at 11:41 AM, Randy Smith <span dir="ltr"><<a href="mailto:rdsmith@chromium.org" target="_blank" class="cremed">rdsmith@chromium.org</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><br><div>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: </div>
<div>* 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?</div>
<div>* Does a decl always have an origin decl, even if it was loaded from an ASTContext (?) that has a complete definition?</div><div>* 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.</div>
<div><br></div><div>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(). </div>
<div><br></div><div>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 :-}.)</div>
<div><br></div><div>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 :-}.</div>
<div><br></div><div>Any thoughts anyone has would be welcome.</div><span><font color="#888888"><div><br></div><div>-- Randy</div><div><br></div></font></span></div>
<br></div></div>_______________________________________________<br>
lldb-dev mailing list<br>
<a href="mailto:lldb-dev@cs.uiuc.edu" target="_blank" class="cremed">lldb-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev" target="_blank" class="cremed">http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div><br></div></div>