RTEMS C++ for MIPS targets
gregory.menke at gsfc.nasa.gov
gregory.menke at gsfc.nasa.gov
Mon Dec 6 21:14:51 UTC 2004
For those building toolchains for MIPS, gcc assumes -G 8 for the
target g++ builds, while it assumes -G 0 for the target gcc. This
leads to problems running C++ code on the MIPS bsps, the symptom is
C++ user programs may exhibit link errors, and those that do link lock
up before the RTEMS banner prints, whereas C builds work fine. Even
if the user code doesn't have global constructors, the C++ library
instantiates a few internally.
It is not sufficient to add
#define MIPS_DEFAULT_GVALUE 0
to gcc/config/mips/rtems.h, this seems to have no effect on the g++
build. I was able to coax the gcc build to add -G 0 for g++ by
setting these environment vars before starting the gcc configure;
export FLAGS_FOR_TARGET="-G 0"
export CXXFLAGS="-G 0"
note, CXX_FLAGS_FOR_TARGET has no effect on the g++ configure or
build. FLAGS_FOR_TARGET seems to be redundant with the default gcc
build, but I went ahead with it.
All RTEMS mips bsp's are supposed to add -G 0 in their respective
make/custom files.
Of course, -G 0 causes all data addressing to be performed via 2
instruction 32 bit pointer operations. RTEMS works fine with -G
values greater than 0 <IF> gcc, rtems and the user app are all
compiled with the same -G value. Since something like this is
unavoidably idiosyncratic, default builds should always use -G 0. In
one benchmark I ran back in the rtems-4.5 days, I got roughly a 10%
speedup by introducing -G 4. Its likely possible to build gcc, g++
and rtems with -G 0, but compile user code with something else and
have it all work, but I've not pursued that question.
Thanks,
Greg Menke
More information about the users
mailing list