linker question: rtti/exception functions

Kai Ruottu kai.ruottu@luukku.com
Thu Feb 14 10:04:00 GMT 2002


Ruppert wrote:
> 
> I have configured gcc-2.95.3 as cross compiler for i386-rtemself and
> have come across a problem when linking a small C++ example program:
> 
> Although I compile everything with -fno-exceptions and -fno-rtti

 "If you give the devil your little finger, it takes your whole arm..."

 Using these options now is too late, you should have a 'libstdc++.a'
which was compiled using them and some exception related functions
(stdexcept) left out from the library...

> I get a bunch of functions from libgcc.a in the final executable which
> are apparently intended for exception and rtti support ( __default_terminate,
> __throw_type_match and many more, apparently all relating to rtti and
> exception handling). To me it looks as if these functions are drawn
> forcibly from libgcc.a (I have also written my own startup code, so I
> am sure that I have not introduced any reference to these functions
> there).

 Using 'i386-rtemself-nm' for the target 'libgcc.a' (with a pipe to 'more'
or 'less') will show these symbols being in the '_eh.o', the 'exception
handling' module and the modules in your 'libstdc++.a' surely require it.
 
> Does anybody know if it is possible to get rid of this (or, how this
> comes about)?

 The right solution would be to produce a '-fno-exceptions' variation
multilib additionally with the default one with exceptions support.
Then using '-fno-exceptions' would imply using the 'libstdc++.a' from
the 'no-exc' (or something) subdir you have tied to this switch.

 Maybe you would like to produce something else, like 'soft-float' variation
of the libs, a 'i486' or 'pentium' variation or something. The following
modified example ('gcc/config/i386/t-i386elf') could help in this :

------------------------ clip ---------------------------------------
# i386-elf embedded configuration target with soft-float.
# by Kai Ruottu

FPBIT = fp-bit.c
DPBIT = dp-bit.c

LIB2FUNCS_EXTRA = xfgnulib.c
 
dp-bit.c: $(srcdir)/config/fp-bit.c
	echo '#define FLOAT_BIT_ORDER_MISMATCH' > dp-bit.c
	cat $(srcdir)/config/fp-bit.c >> dp-bit.c

fp-bit.c: $(srcdir)/config/fp-bit.c
	echo '#define FLOAT' > fp-bit.c
	echo '#define FLOAT_BIT_ORDER_MISMATCH' >> fp-bit.c
	cat $(srcdir)/config/fp-bit.c >> fp-bit.c

MULTILIB_OPTIONS    = m486 mpentium msoft-float fno-exceptions
MULTILIB_DIRNAMES   = 486 soft-fl no-exc
MULTILIB_MATCHES    = mpentium=m586 m80387=mhard-float 
MULTILIB_EXCEPTIONS = mpentium/msoft-float

INSTALL_LIBGCC = install-multilib
LIBGCC = stmp-multilib

LIBGCC1 =
CROSS_LIBGCC1 =

# For i386elf we build crtbegin.o and crtend.o which serve to add begin and
# end labels to the .ctors and .dtors section when we link using gcc.

EXTRA_PARTS=crtbegin.o crtend.o
------------------------ clip ---------------------------------------

 The 'i386-rtemself' target chains the 'gcc/config/i386/t-i386bare' and the
'gcc/config/t-rtems' to be the equivalent of the previous 't-i386elf'. At
least with the plain vanilla FSF sources. If you have any extra patches from
Oarcorp, the situation may be different... Anyway the answer to the "how to
add variations for the produced libs with x86, like in other architectures",
can be seen here... BTW, the 'MULTILIB_EXCEPTIONS = mpentium/msoft-float'
tells that the 'i586SX' doesn't exist, so '-msoft-float' with '-mpentium' is
not needed...
 
 Or you can completely stay with not using exceptions and use only the '-m386'
default for the produced libs. Then editing the 'CXXFLAGS_FOR_TARGET = ' (the
options used with the target g++) in your $build/Makefile to include the needed
'-fno-exceptions' would the solution. The same can be done with the '-fno-rtti'...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com



More information about the crossgcc mailing list