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