Incorrect specs for libstdc++ nano

[stephanosio]

The nano variant of the libstdc++ library (libstdc++_nano.a and libsupc++_nano.a) is not built with the correct specs.

Comparing libstdc++ of Zephyr SDK and GNU Arm Embedded:

Toolchain	libstdc++.a	libstdc++_nano.a
Zephyr SDK	5.4M	5.3M
GNU Arm Embedded	5.5M	3.5M

Note that there is a significant size difference between the full and nano variants of libstdc++ for GNU Arm Embedded, whereas the size difference between these two for Zephyr SDK is minimal.

This difference is due to the fact that the libstdc++ for Zephyr SDK is currently built with only -Os (optimise for space), whereas the libstdc++ for GNU Arm Embedded is built with -Os and -fno-exceptions (no C++ exception handling support).

The decision to disable C++ exception handling support for the nano variant of the libstdc++ library is a sensible one, noting that doing so greatly reduces the final binary size, which can be said to be the whole point of having a separate nano variant.

The following fix should be implemented:

1. Add a crosstool-ng config/scheme that can be used to specfiy -fno-exceptions to CXXFLAGS_FOR_TARGET.
2. Use the above to specify -fno-exceptions for the libstdc++ nano build.

For more information, refer to the issue zephyrproject-rtos/zephyr#35972.

[johngrey-dev]

Just wandering if disabling exceptions for libc-nano is the best choice. maybe have some mix-and-match options to use libc-nano with or without exceptions, cause the library seems to work fine with -fexceptions.

for some reason links are broken, but I also added a comment under the fix commit fd4d880

Hi.
Why disable exceptions in nano altogether?
exceptions is a pretty heavy feature to just remove, where the previous libstdc++ is too large for some targets, libc-nano with exceptions was the perfect fit for embedded apps with exceptions.
Why not have the 3 variants (no covid pun intended) ?
Full libc, libc-nano with exceptions & minimal libc-nano. Then have use CONFIG_EXCEPTIONS and CONFIG_NEWLIB_LIBC_NANO point to the desired one at link?
I can open an issue + PR for this if it can interest the community.

[stephanosio]

newlib-nano and libstdc++-nano are two separate/independent libraries; so, technically speaking, there is no sound reason as to why one must not be able to link newlib-nano with libstdc++-full (which supports C++ exceptions) and vice versa.

The simultaneous linking scheme (of newlib-nano and libstdc++-nano libraries) is currently enforced by the use of nano.specs; but, in theory, as you suggest, there is no technical reason as to why one cannot rework the whole scheme to allow independently linking full and nano variant of each library.

With that said, this fix is intended to work with the status quo (i.e. within the limitations of nano.specs) and tries to align the behaviour of the Zephyr SDK with that of the GNU Arm Embedded, which can be deemed a fairly reasonable reference implementation.

If you would like to post an enhancement issue/PR that would allow independently linking the full and nano variants of the newlib and libstdc++, I would not be against it.