Unexpected/unnecessary Typeinfo symbols included in binary when using C++

Hi Marc,

I have moved this to the TI C/C++ Compiler forum because I think you will probably get better help from our compiler team there. This may be a compiler bug - if you have a simple project that you can share that shows the issue this might be helpful, as well as maybe a log file or something that shows the details of your install and compiler version being used?

Regards,

Katie

Thanks Katie.  Here is my compiler version; is there other info you would want?

$ cl430
MSP430 C/C++ Compiler v4.2.1

This code demonstrates the issue:

#include <cstdio>

class Base {
   public:
      Base() { }
      virtual ~Base() { }
      virtual bool func() { return true; }
};

class Derived : public Base {
   public:
      Derived() { }
      virtual ~Derived() { }
      virtual bool func() { return false; }
};

int main() {
   Base base;
   Derived derived;
   return base.func() != derived.func();
} 

When I run my tool, I can see:

0x0664A [   38] --- OBJECT     Typeinfo name for __cxxabiv1::__si_class_type_info
0x06670 [   34] --- OBJECT     Typeinfo name for __cxxabiv1::__class_type_info
0x067BC [   14] --- OBJECT     Typeinfo name for std::type_info
0x067CA [   12] --- OBJECT     Typeinfo for Derived
0x067D6 [   12] --- OBJECT     Typeinfo for __cxxabiv1::__class_type_info
0x067E2 [   12] --- OBJECT     Typeinfo for __cxxabiv1::__si_class_type_info
0x06806 [   10] --- OBJECT     Typeinfo name for Derived
0x06810 [    8] --- OBJECT     Typeinfo for Base
0x06820 [    8] --- OBJECT     Typeinfo for std::type_info
0x06838 [    6] --- OBJECT     Typeinfo name for Base

Here are the cl430 compiler flags I am using:

--verbose_diagnostics

--emit_warnings_as_errors

-vmspx

--abi=eabi

--gen_func_subsections=on

--opt_for_speed=0

--gcc

--define=__MSP430FR5969__

--diag_warning=225

--display_error_number

--diag_suppress=10374

--diag_suppress=383

--diag_suppress=188

--diag_wrap=off

--silicon_errata=CPU21

--silicon_errata=CPU22

--silicon_errata=CPU40

--printf_support=minimal

--code_model=large

--data_model=restricted

--near_data=none

And linker flags:

--verbose_diagnostics

--emit_warnings_as_errors

-vmspx

--abi=eabi

--gen_func_subsections=on

--opt_for_speed=0

--gcc

--define=__MSP430FR5969__

--diag_warning=225

--display_error_number

--diag_suppress=10374

--diag_suppress=383

--diag_suppress=188

--diag_wrap=off

--silicon_errata=CPU21

--silicon_errata=CPU22

--silicon_errata=CPU40

--printf_support=minimal

--code_model=large

--data_model=restricted

--near_data=none

--verbose

-vmspx

--abi=eabi

-O4

--issue_remarks

-z

--cinit_compression=off

--cinit_hold_wdt=on

--stack_size=2560

--heap_size=160

--use_hw_mpy=F5

--reread_libs

--priority

--warn_sections

--rom_model

--map_file=t3.map

Let me know if there is any other information that would help.

You are experiencing a known bug in the compiler.  You can look up SDSCM00049326 with the SDOWP link below in my signature.  It is present in all current 4.2.x and 4.3.x versions of the MSP430 compiler.  The next set of releases will include a fix.  Visit here for information on those releases.

A partial workaround is to build for the newer EABI with the switch --abi=eabi.  Under that switch the tools do a better job of eliminating unneeded data.  It won't remove all the typeinfo data, but it should avoid some of it.  

Thanks and regards,

-George

Thanks George - that looks like what we are seeing.

Is the current plan to fix this in the 4.3.2 release of the MSP430 compiler toolchain?  I see from the ticket that it has been fixed in a to-be-scheduled release of the C2000 toolchain, but it doesn't mention the MSP430.

Marc Allen said:

Is the current plan to fix this in the 4.3.2 release of the MSP430 compiler toolchain?

Yes.

-George

Hi George,

Is there any update on the release schedule for the next version of the MSP430 compiler that contains a fix for this issue?  I was just looking at the roadmap and it looks like the target date has passed.

Thanks.

SDSCM00049326 was fixed in MSP compiler version 4.3.2, which has been released.  Does it not show up in the update list in CCS?

I did not realize that the update had been released, thanks for pointing that out.

However, after downloading the update and recompiling my code, there is no change and all of the RTTI TypeInfo structures are still there, and there was no improvement in .const section size.  So it looks like this issue was not actually fixed.

Here are my compiler flags:

/home/marc/ti/ccsv6/ccsv6/tools/compiler/msp430_4.3.2/bin/cl430

-O3

--verbose_diagnostics

--emit_warnings_as_errors

-vmspx

--abi=eabi

--gen_func_subsections=on

--opt_for_speed=0

--include_path=/home/marc/ti/ccsv6/ccsv6/ccs_base/msp430/include

--include_path=/home/marc/ti/ccsv6/ccsv6/tools/compiler/msp430_4.3.2/include

--gcc

--define=__MSP430FR5969__

--define=__STDC_LIMIT_MACROS

--diag_warning=225

--display_error_number

--diag_suppress=10374

--diag_suppress=383

--diag_suppress=188

--diag_wrap=off

--silicon_errata=CPU21

--silicon_errata=CPU22

--silicon_errata=CPU40

--printf_support=minimal

--code_model=large

--data_model=restricted

--near_data=none

--verbose

--common=off

--issue_remarks

-z

--cinit_compression=off

--cinit_hold_wdt=on

-I/home/marc/ti/ccsv6/ccsv6/tools/compiler/msp430_4.3.2/lib

--stack_size=2560

--heap_size=160

--use_hw_mpy=F5

--reread_libs

--priority

--warn_sections

--display_error_number

--rom_model

--map_file=t3.map

I'll ask the developer who fixed the bug about this.

Thanks.  This is occupying ~2KB of code space in my application, and I don't even have that many vtables.

I see a difference in object size for the example submitted in SDSCM00049326 when using the MSP 4.3.2 codegen tools release and the -rtti option than I do when I omit the option.   I get the same results for MSP 4.3.1 regardless of whether the -rtti option is used or not.   I also see the difference when using the C2000 6.2.6 release.  It looks from our end that the problem was resolved in the MSP 4.3.2 codegen tools release.   Do you see different results when using the example submitted in SDSCM00049326 with the -rtti option than you do when you omit the option?

-Mack

I have attached a standalone makefile and example that demonstrates that the RTTI is still present in 4.3.2.  See symbols.txt for the output of my analysis tool, and the make.log showing that I was using 4.3.2.  You'll need to modify CCS_PREFIX to build on your own system.

I see these RTTI symbols in the resulting binary:

0x10820 [ 38] --- OBJECT Typeinfo name for __cxxabiv1::__si_class_type_info
0x10846 [ 34] --- OBJECT Typeinfo name for __cxxabiv1::__class_type_info
0x108B0 [ 14] --- OBJECT Typeinfo name for std::type_info
0x108BE [ 12] --- OBJECT Typeinfo for DerivedA
0x108CA [ 12] --- OBJECT Typeinfo for DerivedB
0x108D6 [ 12] --- OBJECT Typeinfo for __cxxabiv1::__class_type_info
0x108E2 [ 12] --- OBJECT Typeinfo for __cxxabiv1::__si_class_type_info
0x108EE [ 10] --- OBJECT Typeinfo name for DerivedA
0x108F8 [ 10] --- OBJECT Typeinfo name for DerivedB
0x10902 [ 8] --- OBJECT Typeinfo for Base
0x1090A [ 8] --- OBJECT Typeinfo for std::type_info
0x10912 [ 6] --- OBJECT Typeinfo name for Base

Let me know if you see the same results.

8130.rtti.tar.gz

Your new test case uses virtual functions, so you get a vtable. Because you are using EABI, each vtable gets a typeinfo, and this is unavoidable, because the typeinfo is needed to support dynamic_cast.  This is as designed.  Now, your test cast does not use dynamic_cast, so I wonder if in some situations we can elide the typeinfo, but as the code is written now, there's no way to avoid it.  We will continue to analyze this case.

The last test also used virtual functions, but it seemed like they were getting optimized out so I modified the test to prevent that from happening.

Usually the intent of omitting the -rtti option is to remove all of the RTTI data structures, therefore preventing dynamic_cast from succeeding, as dynamic_cast is synonymous with RTTI.  I would posit that the current behavior is not meeting the spirit of the feature, as I understand it.

What does -rtti actually do then, if it doesn't dis-include RTTI?

Okay, we believe we've got this figured out.

A lot of the confusion comes from the fact that SDSCM00049326 only applies to COFF.  I've adjusted the external notes on SDSCM00049326 to reflect this.  RTTI and exceptions are implemented differently on COFF.  For COFF, RTTI information is indeed not generated if --rtti is not used.

However, EABI implements RTTI differently, and stores a pointer to the typeinfo structure as part of the virtual function table.  The --rtti option has no effect on the virtual function table in EABI, so if you are using virtual classes in EABI, you will get typeinfo regardless of whether you use --rtti.  RTTI is required for certain operations, such as dynamic_cast from a base type to a derived type, and we can't know when compiling the module that will contain the virtual function table definition whether some other module does such a dynamic cast.

This all operates as designed, and is not a bug.  It may be possible to more aggressively eliminate RTTI for EABI when --rtti is not used, but this must be considered a data size enhancement, and would not be patched onto the 4.2.x branch.  A more in-depth analysis would be required to determine whether this is feasible.

The --rtti option was originally added for COFF, and apparently just got kept in EABI mode.

Thank you for looking into this.  This may be operating as designed, but eliminating RTTI is a standard feature on most commercial embedded compilers that support C++.  These unused RTTI structures, especially the string names, take up a significant amount of space, nearly 2KB.   I could understand having a few root level TypeInfo data structures perhaps, but the string names are a problematic overhead...

Have this issue been solved? I am using TI compiler 5.3.7, and it seems that this issue (class names for class in final bin) is still there. Does version 5.4.x solve this issue?
Thanks

Hi,

  You are right that it is V4.3.7.