<div dir="ltr">From the standard point of view it does appear that this trick is legal btw:<br><br>"A debugging information entry that represents a non-defining or otherwise incomplete declaration of a program entity has a<div>
DW_AT_declaration attribute, which is a flag..."</div><div><br></div><div>so this is merely being labeled as an incomplete type and is valid dwarf.</div><div><br></div><div>I'm not a fan of it necessarily, but a 20% win per object file is huge. I'd honestly prefer that struct types worked more like namespaces, but that's a rather serious change to the standard.</div>
<div><br></div><div>-eric</div><br><div>On Mon Dec 16 2013 at 4:44:25 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
On Dec 16, 2013, at 14:55, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
<br>
><br>
><br>
><br>
> On Mon, Dec 16, 2013 at 2:44 PM, Adrian Prantl <<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>> wrote:<br>
> Hi Chandler and David,<br>
><br>
> unfortunately it looks more like case 1. This optimization breaks several assumptions that tools in our software stack depend on.<br>
><br>
> It's a fairly substantial debug info size savings that seems worth investigating whether you can keep it enabled at least in<br>
<br>
this sentence is cut off in the middle :-)<br>
But extrapolating from that: For (LTO) builds we still have type uniquing which gets us the same kind of improvement and more.<br>
<br>
><br>
> - For example, it breaks dtrace, which on Darwin relies on being able to pull the (complete) CTF info (compact C type format) out of the DWARF in the .dSYM for a given module.<br>
><br>
> I take it you're already using -fno-limit-debug-info for these scenarios, then? (are you using -flimit-debug-info at all?)<br>
<br>
Currently I believe that -flimit-debug-info is the default on Darwin. I don’t know what you mean by “these scenarios”; “we" can’t anticipate what programs users may want to probe using dtrace.<br>
><br>
> - Kernel extensions tend to inherit from base classes that are defined in a system framework (I/O Kit works this way for example).<br>
><br>
> And the library where the base class is defined isn't built with debug info as a matter of course? Is that solvable at all?<br>
<br>
Of course — by not performing this optimization, the type info for the base class ends up in the user’s .o file, as it always used to. This is just one example to make the "user code that inherits from base classes defined in 3rd-party C++ library” scenario I mentioned yesterday more real.<br>

><br>
> - For LLDB it is not always possible to tell where a type came from and vtable symbols can get stripped from the symbol table.<br>
><br>
> I don't understand the relevance of vtable stripping to this issue - could you explain it to me? (are you suggesting that the vtable symbol lookup could/would be used to locate the right object file/dsym to load the full definition of the type? I'm only vaguely familiar with such an idea and didn't realize you could get from the symbol back to the object file and thus to the dsym).<br>

><br>
> If it can’t layout the type, the expression evaluator doesn’t work.<br>
><br>
> We do need to have the option to turn this optimization off; preferably we would make off the default for Darwin. Other platforms that use LLDB as their primary debugger may want to do the same thing.<br>
><br>
> Is there no way to fix LLDB so it actually loads in the other dsyms and finds the full definition of the type? It would seem unfortunate to have such a bloated debug info format (not only for this optimization, but for the existing -flimit-debug-info optimizations and anything else we might think of in the future where we can ensure that some debug info is already availabel in another file).<br>

<br>
I think Greg commented on the LLDB side of things already.<br>
<br>
-- adrian<br>
______________________________<u></u><u></u>_________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@cs.uiuc.edu" target="_blank">cfe-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailm<u></u>an/listinfo/cfe-commits</a><br>
</blockquote></div>