threading support with custom kernel?

[Fery <engard dot ferenc at innomed dot hu>]

Hi all,

First of all, I greet everybody on this list as this is my first mail
here.

I develop an embedded app for a Renesas SH2 processor, with a home-made
multi-threading kernel. The used GCC is not compiled by me (but by
www.kpit.com), its version is 3.3-GNUSH_v0401. I don't use exceptions,
rtti, and used only small portions of libc and stdc++ so far (malloc,
memcpy, new...). Recently I have decided to use STL classes in the app.
Here I share some success, and some issues I couldn't figure out yet.

1. The size problem.

The trivial test file with this content:

#include <vector>
std::vector<int> v;

enlarged my project with cca. 250KB. Practically it included half of
libc and stdc++ into our project: streams, locale, exception support...
This was unaffordable, so I hunted down the lib to find the reason.

I have found the file libdtsc++-v3/src/functexcept.cc. Here are numerous
__throw_*() functions, which have two variations based on the
__EXCEPTIONS macro, one throwing error objects (and forcing many unused
parts of the lib in the binary), and one calling abort(). I needed the
second one, but the lib contained the first one, so I have copied this
file into my project, and compiled without defining __EXCEPTIONS, and
the size problem has been solved. Is it a good solution, or there is a
not-so-hackish method?

2. Threading support.

I couldn't find documentation about what I have to do to use STL on my
custom multi-threading kernel. I have found the gthr*.h include files,
and I can implement the needed macros and functions, but I do not know
what to do with it. Do I need to recompile libstdc++? If so, how to do
it with my gthr.h header file?

The libstdc++-v3 FAQ 5.6 section says that if gcc -v reports thread
model single then libstdc++ cannot be thread-safe. My toolchain reports
single. Does it mean that providing this gthr*.h is not enough? I do not
want to compile the crosscompiler, if it is possible...

Is it an alternative solution if I do not use the default
__default_alloc_template<>? If it is, is there a method to globally
redefine the default allocator to, say, malloc_alloc_template<>? I have
implemented the __malloc_(un)?lock() functions, so malloc works
properly.

Thanks in advance:
Ferenc Engard