libstdc++ with RTTI (i.e. without -fno-rtti) (IDFGH-751)

[jovermann]

Apparently the libstdc++ in the current toolchain (xtensa-esp32-elf-linux64-1.22.0-75-gbaf03c2-5.2.0.tar.gz) is compiled with -fno-rtti.

I have a project which relies on RTTI and I modified project.mk to have -frtti instead of -fno-rtti. This compiled fine, but when linking I get lots of errors like:

undefined reference to `typeinfo for std::basic_istream<char, std::char_traits >'

for various types of course. I think this is because libstdc++ is compiled with -fno-rtti.

Request: Please compile libstdc++ in the toolchain with -frtti (or with no rtti flag at all because RTTI is enabled by default). Please change the default flags for CXX to -frtti (or to no rtti flag at all because RTTI is enabled by defaul).

The linker will ignore the additional data when it is not needed, so I do not see a drawback.

I currently see non-deterministic crashes when doing dynamic_cast on user defined types which are derived from std:: types (like locale etc). This is perfectly explainable since the RTTI settings between my code and libstdc++ are inconsistent. But as an esp-idf user I have no way to fix libstdc++.

[chengyuhui]

Any update on this?

Recently I have been trying to get https://github.com/ThePhD/sol2 running on EPS32, which depends on rtti to compile successfully.

[igrr]

The linker will ignore the additional data when it is not needed, so I do not see a drawback.

Unfortunately, this is not entirely the case. If RTTI is enabled when compiling libstdc++.a, then vtables of classes compiled into libstdc++.a will contain pointers to the typeinfo structures. When such classes are used in the application, typeinfo structures will also be linked, because they are referenced from vtables. This will be the case even if the application does not enable RTTI. In some tests we have seen increase of application binary size by 10kB or more.

We are looking into approaches to reduce this penalty for users who do not need to enable RTTI.

[v1993]

@igrr Can't you build libstdc++ together with project and not provide pre-compiled library? That would introduce some time penalty for complete rebuilds, but they aren't required pretty often I think.

[bpietsch]

Or provide two versions of the library and choose which to link to based on whether rtti was used in the project via the makefile?

[v1993]

@bpietsch Yep, that would work as well I guess. Options from "menuconfig" can be read from CMake/Makefiles.

[igrr]

Can't you build libstdc++ together with project and not provide pre-compiled library?

It's not exactly trivial for a couple of reasons. First, it is hard to separate libstdc++v3 from the rest of the GCC repository, and still have the correct ./configure behavior. Second, libstdc++v3 has a dependency on autoconf and make. The former was never a requirement for ESP-IDF, the latter is not a requirement for the users of CMake build system.

Or provide two versions of the library and choose which to link to based on whether rtti was used in the project via the makefile?

This is possible, but will need some tweaks to the toolchain build process. Currently we use crosstool-NG to build the toolchain, and building multiple copies of libstdc++.a is not supported out of the box there.

GCC's multilib support is another option, we already use it to produce a separate set of libraries for the PSRAM case. However that would result in bundling of extra copies of libc.a, libm.a, libgcc.a, which do not actually depend on RTTI.

Yet another option is to keep RTTI enabled in libstdc++ build, but modify the linker script to place typeinfo structures into a non-loadable section, so that they would not contribute to the binary size, while technically still be linked into the application.

We will be exploring these options and this issue will be updated when there is some progress.

[bpietsch]

Thank you Ivan, appreciate your efforts to come to a resolution on this!

[davidthings]

Hi! My development just came to a halt with this problem too. We have a lot of C++ code that does rely on RTTI, so RTTI must be on. Sadly this causes an "undefined reference to typeinfo for std::thread::_State" error when linking. It looks like this problem is limited to a couple of calls into the standard thread library - creating threads.

It's hard for me to see a work around here. And I for one agree with the poster at the top who says that leaving RTTI default on (RTTI users' code works, non RTTI users' code is a little bigger) might be a gentler compromise than default off (RTTI users' code doesn't work, non RTTI users' code is a little smaller)

Help! What is the latest for a resolution for this issue?

[mirronelli]

Is there at least some kind of a workaround for this? My projects are halted too because of this. I have to use older esp_idf commits to build those projects.
Ivan Grokhotkov you have mentioned in a linked post that some form of dependency could be added to libstc++.a so that the references are resolved, but there was no followup on that, how to do so. Is that still a possibility?
If not how can I force my project to be built with no RTTI support so that it builds. Anyway are there any news about how you plan to solve it?
Thanks.

[drony]

thank you. which version toolchain works with this update. Toolchain 2.1 version seems doesn't work

[igrr]

@drony what do you see when you run xtensa-esp32-elf-gcc --version? It should be xtensa-esp32-elf-gcc (crosstool-NG esp-2019r2) 8.2.0. If it isn't, please follow the docs for installing the tools: https://docs.espressif.com/projects/esp-idf/en/latest/get-started/index.html#step-3-set-up-the-tools

[drony]

yes it's same version
xtensa-esp32-elf-gcc (crosstool-NG esp-2019r2) 8.2.0
also i'm using idf 4.0beta2
but idf.py menuconfig doesn't show setttings under compiler menu

[igrr]

Ah, that's right. RTTI support is not part of IDF release/v4.0 branch. It has been added in master in commit 959ca74, and will be part of the next release (IDF 4.1).

[drony]

:( when will this version be released? beta or preview