https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117683
Bug ID: 117683
Summary: provide a way to remove all C++ class names from the
binary
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rdiez-2006 at rd10 dot de
Target Milestone: ---
I am writing embedded software for very resource-constrained microcontrollers,
and I have noticed that the C++ class names end up in the binary, even if never
used.
These class names have to do with the typeid operator and the std::type_info
class.
Example code:
class very_very_long_class_name_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
{
public:
virtual void some_method ( void )
{
}
};
static const very_very_long_class_name_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
static_instance;
int main ( void )
{
return 5;
}
Run this command to verify it:
$ g++ typeinfo.cpp && strip a.out && strings a.out | grep very
55very_very_long_class_name_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Tool 'objdump' prints this line for a.out:
0000000000002020 w O .rodata 000000000000003a typeinfo name for
very_very_long_class_name_xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
This probably has to do with vtables, and is similar to bug 117672 ("Remove
unused virtual methods"). Once that bug is fixed, these class names may be
optimised away if unused.
There is a difference however: I would like to forcibly remove all those class
names from the binaries, in order to save program space (flash memory).
Class names can be rather long if nested classes and templates are involved.
Besides, I don't like having to shorten the names just to save memory.
I have read the following on the Internet:
-----8<-----8<-----8<-----
std::type_info::name
const char* name() const;
Returns an implementation defined null-terminated character string containing
the name of the type. No guarantees are given; in particular, the returned
string can be identical for several types and change between invocations of the
same program.
-----8<-----8<-----8<-----
Because there are no guarantees (allegedly), I am guessing it should be OK to
always return an empty string.