Assigning to an "extern" variable does not cause type information to be emitted

[labath]

$ clang -c -o - -x c++ -g - <<<"struct S {}; extern S *s; void f() {s = new S(); }" | llvm-dwarfdump - | grep DW_TAG_structure_type
$ clang -c -o - -x c++ -g - <<<"struct S {}; S *s; void f() {s = new S(); }" | llvm-dwarfdump - | grep DW_TAG_structure_type
0x00000033:   DW_TAG_structure_type

I believe the first command should also produce debug info for struct S. We cannot rely on the type information to be emitted in the compilation unit defining s as it may not even have access to the definition (it could be treating it opaquely as a forward-declaration). Interestingly, not even -fstandalone-debug causes the type to be emitted.

[llvmbot]

@llvm/issue-subscribers-debuginfo

Author: Pavel Labath (labath)

``` $ clang -c -o - -x c++ -g - <<<"struct S {}; extern S *s; void f() {s = new S(); }" | llvm-dwarfdump - | grep DW_TAG_structure_type $ clang -c -o - -x c++ -g - <<<"struct S {}; S *s; void f() {s = new S(); }" | llvm-dwarfdump - | grep DW_TAG_structure_type 0x00000033: DW_TAG_structure_type ```

I believe the first command should also produce debug info for struct S. We cannot rely on the type information to be emitted in the compilation unit defining s as it may not even have access to the definition (it could be treating it opaquely as a forward-declaration). Interestingly, not even -fstandalone-debug causes the type to be emitted.

[dwblaikie]

What does GCC do in these situations?

LLVM used to have some special cases for emitting type info for otherwise unreferenced types - mostly I removed that to use the more consistent "requires complete type" stuff. Though we have some exceptions for enumerations still...

We can add some more special cases, though I tend to hesitate to do so.

Is there a real world example that inspired this bug? Could you sketch it out? (it might show various facets we could rely on to pin the debug info emission)

[labath]

What does GCC do in these situations?

GCC will emit the type information (in both cases).

Is there a real world example that inspired this bug? Could you sketch it out?

I ran into this while writing a test case, but the real world use case I was modelling was a library which provides some type to its clients as an opaque handle. FILE * is one such example. The value is only meant to be used opaquely by the clients so the C library could (and I understand some implementations do that) only provide a forward declaration in the public header, and only define it internally.

Now, an actual library is not likely to define its API in terms of (extern) global variables -- that was the simplification I made for the test case. It would probably pass the handles around through function arguments, which is sufficient to cause the type to be generated.

I know know you meant that (the type is not referenced in the debug info), but I have a problem calling this type "unreferenced" -- the source code definitely references it.

Two more thoughts:

• Maybe we should think about this as a bug in the constructor homing -- the code definitely constructs an object of that type. In fact, clang also does not generate debug info for T in code like struct S {}; struct T : S {}; S* f() { return new T(); } even though T is being constructed. I suppose handing out a private subclasses of a public type could be another (strange) way to implement opaque handles. If the private type is not used in any of the function signatures, then it wouldn't be emitted.
• in the original example, gcc also emits a forward declaration for the variable s (presumably because it's referenced from the body of the function). I guess that would be enough to call the type referenced at the debug info level (?) However, that wouldn't help with the subclass example above..

[dwblaikie]

All the homing strategies are only to reduce the number of places a type shows up, not increase it. (given a set of places the type info shows up, a homing strategy is a way to select some subset of those places that are guaranteed to be present/linked into the program that uses the other places)

Some other examples to probe GCC's behavior, mostly to inspire questions/considerations for what kind of design we might want:

This includes the S type:

extern S* s;
void f1() {
  int x= s->i; // produces
  (void)s->i; // does not produce
  f(s->)i; // produces
}
inline void f2() {
  int i = s->i; // does not produce, if f2 is not code generated
}

So, looks to me like GCC's probably motivating this by the frontend's code generation of something requiring the complete type of s.
It's certainly something we discussed back when I implemented the requires complete type type emission strategy (prior to that we did have some adhoc solutions that probably were closer to/did address what this bug is about - they looked for particular code generated expressions) - for instance clang would produce full type information in a situation like this: struct S { }; inline void f1() { S s; } void func(S* s) { } (GCC doesn't do the non-requires-complete type elision, so we can't really compare much here - it produces the whole definition because it's available and S is referenced from the DWARF)

Oh, by "unreferenced" - I mean from a DWARF-rooted-in-definitions perspective. If DWARF starts at definitions that produce code, and follows anything needed to describe those things (parameters, local variables, etc) then in that very particular sense, the type is not referenced by the DWARF graph. By default, Clang/LLVM's type information is only held alive by that graph - so even if Clang produced it, it wouldn't make it into the IR if it wasn't reachable by that graph, rooted in llvm functions and global variables.

We do have "retainedTypes" to handle cases where we need to override that graph reachability problem, to force a type to always be emitted regardless of its reachability - but that's a hammer to wield carefully because it means linker optimizations that remove code can't remove those potentially now unused types.

We could maybe try to identify the expression types that bind a type and dereference it, to emit the type into retainedTypes if the type isn't otherwise emitted. That'd be motivated by clang's irgen, which should give similar behavior to GCC here. It seems a bit brittle/subtle/likely to miss cases (now or in the future), though... but such is life I guess.

Best make sure such a solution is at the IRGen/Clang CodeGen level, so it doesn't trigger for unused inline functions, etc.

[dwblaikie]

As for a forward declaration of the global variable declaration - emitting that should probably only be done under -fstandalone-debug - in non-standalone mode, we should rely on it being present from wherever that global is defined.