[cfe-dev] Catching Temporarily Used Types in Debug Info

[Adrian Prantl]

Hi David!

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...


On Mar 3, 2014, at 8:41 AM, David Blaikie <dblaikie at gmail.com> wrote:

> We have a few bugs like ( http://llvm.org/bugs/show_bug.cgi?id=19005 )
> in debug info that all stem from the same basic problem:
> 
> A type that's not referenced by another debug entity (such as a
> variable, parameter, function, etc) is not emitted in the debug info.
> 
> GCC, while not being wholely consistent at addressing this, does get
> it 'more' right. I'd like Clang to be better at this as well, even if
> we're not perfect.
> 
> The basic premise to implement this perfectly would be: If we're
> emitting code for a function (or global variable initializer, etc) and
> within that function a certain type is required to be complete, emit
> the type (and include it in the "retained types list").
> 
> Does anyone have nice ideas on how we could realistically implement
> that test (yeah, I'm mostly looking at Richard on this) or a rough
> approximation that might get the 90% case?

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)?

I guess this is really a question for the frontend people :-)
> 
> And as a bonus it'd probably be good if we didn't do this for cases
> where we already successfully emit the type (eg: if it's required to
> be complete because there's a variable of that type we'd rather not
> add that type to the retained types list needlessly... but there are
> some wrinkles there)
> 
> Some examples:
> 
> Neither GCC nor Clang emit 'foo' here:
> 
> struct foo {
> foo();
> int i;
> };
> 
> void func(int);
> 
> void func() {
> func(foo().i + 1);
> }
> 
> int main() {
> }
> 
> but GCC does emit it if the foo ctor called is not the default (
> declare 'foo(int)' and use 'foo(3).i' instead of 'foo().i').
> 
> And the previously linked bug amounts to "func(((foo*)v)->i + 1);"
> (for some "void* v") - in which GCC does emit 'foo' and Clang does
> not.
> 
> So, yes - nothing terribly consistent. It would nice to do better
> (better than we are, maybe even better than GCC, or at least more
> consistent).

-- adrian