There are a number of considerations when using C++ exceptions:
Care should be taken when compiling C++ code with
-fexceptions(the default). GNU C++ has been designed so that exceptions do not necessarily add overhead to functions. However they may add overhead in the following circumstances. Namely, when:
Exceptions are actually used; OR
The function (funcA) calls another function (funcB) with a non-null exception specifier or no exception specifier; AND
that function (funcA) contains an automatic object; AND
that object is defined to use a destructor, and would therefore need to have the destructor called if the called function (funcB) threw an exception through this stack frame.
Not all eCos API functions have null exception specifiers yet, which may lead to very small unnecessary overhead when used from C++ functions in certain circumstances described earlier. Annotating all functions with null exception specifiers throughout the entirety of eCos is a massive job beyond the scope of the work done to provide C++ support. However many of the key APIs can be updated. In the current eCos sources, some obvious APIs have been updated such as all of the kernel C API and much of the ISO C/POSIX APIs.
Exceptions thrown from signal handlers are not supported.
Exceptions are not supported in ISRs, DSRs, nor ASRs. It is neither feasible nor sensible to support exceptions in ISRs or DSRs. Support for ASRs may be added at a future date, although there are no plans at present.
Use of C++ support from this package can increase the thread stack requirements markedly. For example, if you use C++ exceptions, you should expect to add around 4Kbytes to your stack requirements for each thread which can throw exceptions. Developers may find it useful to enable kernel thread stack overflow checking (
CYGFUN_KERNEL_THREADS_STACK_CHECKINGand possibly also
CYGFUN_KERNEL_ALL_THREADS_STACK_CHECKING), especially if erratic behaviour is observed in threads using C++ features.
It is widely acknowledged that when using C++ libraries, memory can quickly be consumed, particularly code (ROM/Flash) space. Small targets may have difficulty running even short C++ programs. For example, it is recommended to use the MEC01 memory extension card on the Atmel AT91 evaluation board platforms (EB40, EB40A, EB42, EB55) to provide extra space for applications. The eCosPro AT91EB40A port can take advantage of the MEC01 if eCos is configured with CYGHWR_HAL_ARM_AT91_EB40A_MEC01_RAM enabled.
Similarly, because of the generally larger code size, download times can be lengthy if using a slow transfer mechanism such as 38400 bps serial. Alternative download options such as ethernet or fast JTAG emulator should be considered for an efficient development/debug cycle.
It may be possible in future to reduce the code size overhead using linker garbage collection more fully. Currently linker garbage collection is not performed on the GNU standard C++ library itself. However it is anticipated the savings will turn out to be small.
eCos itself is not built with exception support
for the reasons
given earlier concerning the overhead of exception
support. As a consequence throwing exceptions from callbacks
will not work, e.g. when using
bsearch(), etc. eCos does not yet
support a means of building individual files with differing
flags - flags are manipulated only for complete packages or by using custom build rules which would be
unacceptable due to maintenance overheads.
The GNU standard C++ library has its own license distinct from that of eCos. As a basis it uses, like eCos, the GNU General Public License. Also like eCos it includes an exception that permits the use of the library in proprietary applications. The exception is as follows:
As a special exception, you may use this file as part of a free software library without restriction. Specifically, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other files to produce an executable, this file does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License.
This exception is very similar to the eCos GPL exception, and is compatible with it. Further information on this license can be found in the Introduction of the libstdc++ online documentation set.
Most of the test files imported from the libstdc++ testsuite are covered by the full GPL without any exception. This means that distributing binaries of the test executables themselves gives a requirement to make available the full source code of that binary under the terms of the GPL. This is not considered an onerous obligation as distributing test binaries for this testsuite publically is unlikely to be a common requirement.
At this time there are only two significant known open issues that developers should be aware of which may impact development:
GCC 3.3.x misoptimizes code in functions with complex number parameters. The workaround is to compile without -O2 (or append -O0 to the end of the compile line). This issue has been filed with the GCC project as bug #15061. As a consequence of this compiler bug, the complex2 test in this package is likely to fail.
GCC 3.3.x fails to return NULL when using the std::nothrow variant of the
newoperator when an amount of memory is requested beyond what the system has available. Instead of NULL, 4 is returned. This is listed with the GCC project as bug #13215 and the problem is not going to be addressed in the GCC 3.3.x series. The problem is fixed in GCC 3.4. As a consequence of this compiler bug, the new1 test in this package will fail with GCC 3.3.x.
The only known issue affecting the use of GCC 3.4.x is specific to M68K/Coldfire, where the software floating point emulation is too imprecise, and causes a small number of tests within the libstdc++ package to fail, primarily those that test long double support.
It is worth mentioning that, as previously mentioned above, wide character support is not included. Support for wide characters may be developed in due course, but it would require significant development in the underlying eCos C library.