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
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_CHECKING and possibly
especially if erratic behaviour is observed in threads using C++
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
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 qsort(),
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
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
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 new operator 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
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
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