<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 3, 2014 at 11:17 AM, David Blaikie <span dir="ltr"><<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.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"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="">On Mon, Mar 3, 2014 at 10:37 AM, Adrian Prantl <span dir="ltr"><<a href="mailto:aprantl@apple.com" target="_blank">aprantl@apple.com</a>></span> wrote:<br>
</div><div class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi David!<br>
<br>
Slightly tangential, but this also reminds me that I eventually was going to send out a proposal for debug info for Modules/PCH. Having access to the serialized AST in its entirety would eliminate problems like this nicely. DWARF is extended by an external AST type DIE that is merely a USR-based index into the corresponding module file. Everything that is not explicitly referenced in the DWARF can still be found in the module/PCH and read via libclang...<br>
<div><br>
<br>
On Mar 3, 2014, at 8:41 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> wrote:<br>
<br>
> We have a few bugs like ( <a href="http://llvm.org/bugs/show_bug.cgi?id=19005" target="_blank">http://llvm.org/bugs/show_bug.cgi?id=19005</a> )<br>
> in debug info that all stem from the same basic problem:<br>
><br>
> A type that's not referenced by another debug entity (such as a<br>
> variable, parameter, function, etc) is not emitted in the debug info.<br>
><br>
> GCC, while not being wholely consistent at addressing this, does get<br>
> it 'more' right. I'd like Clang to be better at this as well, even if<br>
> we're not perfect.<br>
><br>
> The basic premise to implement this perfectly would be: If we're<br>
> emitting code for a function (or global variable initializer, etc) and<br>
> within that function a certain type is required to be complete, emit<br>
> the type (and include it in the "retained types list").<br>
><br>
> Does anyone have nice ideas on how we could realistically implement<br>
> that test (yeah, I'm mostly looking at Richard on this) or a rough<br>
> approximation that might get the 90% case?<br>
<br>
</div>The idea would be for the fronted to register a record type as debug-info-retained whenever, e.g., it is calculating the record's memory layout (or similar)?<br>
<br>
I guess this is really a question for the frontend people :-)</blockquote></div><div><br>Hence this thread :) <br><br>What you described is essentially "required complete type" which is a thing we already know - but we don't really want to go around emitting every type that is required to be complete. Consider this header:<br>
<br>struct foo {<br>...</div><div>}; <br>inline void func() {<br> foo f; <br> ... <br>}<br><br>Now any translation unit that includes that header, even if it doesn't use 'foo' at all and never calls 'func', would emit foo (since foo is required to be complete due to the 'f' variable in the 'func' function). Now consider that Sema.h looks exactly like this.<br>
<br>An example use where we wouldn't want to emit 'foo's definition:<br><br>bar.h:<br>#include "foo.h"<br>class bar { <br> foo *f;<br>public:<br> bar();<br> int compute_thing_with_foo();<br>};<br>
<br>The out of line member function and ctor use the full definition of 'foo', but 'bar' does not, neither do clients of 'bar' need to. It'd be nice if we didn't emit the full definition of 'foo' here.<br>
<br>Richard and I talked through some of this a bit and considered two solutions<br><br>1) essentially what we had before I made the change to power -flimit-debug-info/-fstandalone-debug (prior to the vtable optimization going in there too) by "requiresCompleteType": callback during Clang's IRGen for various AST constructs that we know require types to be complete, and emit debug info for those types. This is a bit painful since we essentially ad-hoc implement complete type detection again... - but I might be OK with this going into it knowing how/why we have to do this and taking a somewhat more systematic approach.<br>
<br>2) Have a callback at every point a type was required to be complete, even if it was already complete (currently we just have a callback on the instnant the type is first required to be complete) and if necessary, record the context in which that type was required to be complete (eg: as a member of another type, as a use in a function, etc). Then if/when we emit that contextual decl, check if any types were associated with it and emit those - recursively expanding (since the associated type might itself be the contextual decl for some other type).<br>
</div></div></div></div></blockquote><div><br></div><div>As a nuance here, we only need the extra cost here if we're in a context that we don't know for sure that we're going to emit (inside an inline function definition or a class definition). Inside a normal function definition, we can just directly register the type to have debug info emitted, if we've not already done so.</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 class="gmail_extra"><div class="gmail_quote"><div>I'm erring towards the latter, though we know in both cases there might be gotchas for all manner of things that we need to blacklist/whitelist to get to a good place... <span class="HOEnZb"><font color="#888888"><br>
<br>- David</font></span></div></div></div></div>
</blockquote></div><br></div></div>