<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, Dec 14, 2016 at 3:06 PM Adrian Prantl <<a href="mailto:aprantl@apple.com">aprantl@apple.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="gmail_msg">
> On Dec 14, 2016, at 2:58 PM, Adrian Prantl via Phabricator <<a href="mailto:reviews@reviews.llvm.org" class="gmail_msg" target="_blank">reviews@reviews.llvm.org</a>> wrote:<br class="gmail_msg">
><br class="gmail_msg">
> aprantl added a comment.<br class="gmail_msg">
><br class="gmail_msg">
> This sounds like it could break debugging with LLDB. If I understand the description correctly, this is the equivalent of doing -fno-standalone-debug?<br class="gmail_msg">
><br class="gmail_msg">
><br class="gmail_msg">
> <a href="https://reviews.llvm.org/D27775" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D27775</a><br class="gmail_msg">
><br class="gmail_msg">
<br class="gmail_msg">
Hmm.. maybe it isn't. The -fno-standalone-debug option was necessary to not omit definitions for classes whose vtable was defined in a third-party library.<br class="gmail_msg"></blockquote><div><br></div><div>Right - the specific case was base classes that were merely declarations. Asking Clang to create the AST for a type deriving from a declaration would assert. (because lldb won't cross-reference other debug info when in the "build the AST" step - it doesn't go off to see if there's a definition elsewhere before asking Clang to build the AST)<br><br>I was going to say, presumably, this could come up in other places - if you tried to build the AST for a function that had a pass-by-value parameter, but you only had a declaration for the parameter type. But I guess LLDB doesn't build an AST for functions - just for types. But maybe it'd trip over some other part of LLDB.<br><br>If that's the case then this /may/ be LLDB compatible, but it's not -fstandalone-debug compatible (rather than tailoring Clang to LLDB's specific needs we ended up discussing what the general principal was that we could encode into the flag to help users determine whether these optimizations were right for them).<br><br>So, ideally, I'd like clang -fno-standalone-debug to not trigger this optimization in gold (pass down the appropriate flag, or whatnot).<br><br>But it's a fairly academic argument & there's no practical reason you couldn't have this optimization on for LLDB. (also, there's no reason you couldn't have the first of the three -fstandalone-debug optimizations on for LLDB either (the first is "if this type is not required to be complete, produce a declaration") but I can't think of a good principled way to justify one over the other in the abstract)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
+Greg, can LLDB can deal with a forward-declaration to a composite type for which a full definition exists in a different translation unit? When debugging from .o file, and when debugging from a .dSYM?<br class="gmail_msg">
<br class="gmail_msg">
-- adrian<br class="gmail_msg">
</blockquote></div></div>