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.

Reply via email to