Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[DebugInfo] Add flag to only emit referenced member functions (#87018)
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 ns
```
a.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 -gomit-unreferenced-members: 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.
So for total clang binary size (I don't have a quick "debug section size
reduction" on-hand): 1.45 (no type units) GiB -> 1.34 -> 1.22, so it
saves about 120MiB of binary size.
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.
Original Differential Revision: https://reviews.llvm.org/D152017- Loading branch information
