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

[Adrian Prantl]

On Mar 3, 2014, at 10:41 AM, Eric Christopher <echristo at gmail.com> wrote:

> On Mon, Mar 3, 2014 at 10:37 AM, Adrian Prantl <aprantl at apple.com> wrote:
>> 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...
> 
> In general this is an insufficient solution to the problem of modules
> debugging. It revlocks the compiler and the debugger and isn't
> suitable for long term archival purposes. It's a "handy if there,
> possibly", but unlikely to be more than an occasionally useful
> extension.

Right, there are actually more nuances to the module debugging story :-)
What I described above was the “development”-use-case.
I just looked at my notes from when we last discussed this, and I believe we came to the conclusion that for the long-term archival scenario clang should emit full DWARF for an entire module when the module is created. On Darwin, for instance, the DWARF for the module would then be archived by dsymutil.
A consumer would first attempt to directly load types from the module, if that fails (e.g., because of version mismatch) it can reconstruct the type from DWARF.

-- adrian

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