[DebugInfo] Add flag to only emit referenced member functions
Complete C++ type information can be quite expensive - and there's limited value in representing every member function, even those that can't be called (we don't do similarly for every non-member function anyway). So add a flag to opt out of this behavior for experimenting with this more terse behavior.
I think Sony already does this by default, so perhaps with a change to the defaults, Sony can migrate to this rather than a downstream patch.
This breaks current debuggers in some expected ways - but those breakages are visible without this feature too. Consider member function template instantiations - they can't be consistently enumerated in every translation unit:
a.h:
struct t1 {
template <int i>
static int f1() {
return i;
}
};
namespace ns {
template <int i>
int f1() {
return i;
}
} // namespace nsa.cpp:
void f1() {
t1::f1<0>();
ns::f1<0>();
}b.cpp:
void f1();
int main() {
f1();
t1::f1<1>();
ns::f1<1>();
}(gdb) p ns::f1<0>() $1 = 0 (gdb) p ns::f1<1>() $2 = 1 (gdb) p t1::f1<0>() Couldn't find method t1::f1<0> (gdb) p t1::f1<1>() $3 = 1 (gdb) s f1 () at a.cpp:3 3 t1::f1<0>(); (gdb) p t1::f1<0>() $4 = 0 (gdb) p t1::f1<1>() Couldn't find method t1::f1<1> (gdb)
(other similar non-canonical features are implicit special members (copy/move ctor/assignment operator, default ctor) and nested types (eg: pimpl idiom, where the nested type is declared-but-not-defined in one TU, and defined in another TU))
lldb can't parse the template expressions above, so I'm not sure how to test it there, but I'd guess it has similar problems. ( https://stackoverflow.com/questions/64602475/how-to-print-value-returned-by-template-member-function-in-gdb-lldb-debugging so... I guess that's just totally not supported in lldb, how unfortunate. And implicit special members are instantiated implicitly by lldb, so missing those doesn't tickle the same issue)
Some very rudimentary numbers for a clang debug build:
.debug_info section size:
-g: 476MiB
-g -fdebug-types-section: 357MiB
-g -gincomplete-types: 340MiB
Though it also means a major reduction in .debug_str size, -fdebug-types-section doesn't reduce string usage (so the first two examples have the same .debug_str size, 247MiB), down to 175MiB.
Total debug info section size reduction is 13% - though different workloads will have different tradeoffs. (& haven't tested with compression enabled - since most of the win is in strings, and strings are quite compressible, this might not account for much in that case - though not having to decompress inputs to the debugger, etc, is valuable)
Also open to any riffing on the flag name for sure.
@probinson - would this be an accurate upstreaming of your internal handling/would you use this functionality? If it wouldn't be useful to you, it's maybe not worth adding upstream yet - not sure we'll use it at Google, but if it was useful to you folks and meant other folks could test with it it seemed maybe useful.