if working with a softfloat toolchain, we end up with copies of softfloat symbols everywhere (from fp-bit.c and dp-bit.c). should these files really end up with symbols with hidden visibility ? seems like a waste to force copying of these symbols into binaries when libgcc_s.so itself already has a copy of them, and when dealing with softfloat toolchains, most things need this library loaded anyways.
this behavior can be seen with bfin-linux-uclibc and sh4-linux-gnu toolchains.
$ bfin-linux-uclibc-readelf -s libgcc.a | grep unpack
14: 00000000 152 FUNC GLOBAL HIDDEN 1 ___unpack_f
14: 00000000 198 FUNC GLOBAL HIDDEN 1 ___unpack_d
$ bfin-linux-uclibc-readelf -s libgcc_s.so | grep unpack
244: 00006a44 198 FUNC LOCAL DEFAULT 10 ___unpack_d
250: 00005ef4 152 FUNC LOCAL DEFAULT 10 ___unpack_f
then looking a typical Linux build, we see these symbols being copied into the
C library and many basic libraries (ncurses/ts/etc...) as well as programs
(shell/etc...). even though they're also linked against libgcc_s.so, the
libgcc.a archive provided the symbols since they werent exported from
libgcc_s.so.
perhaps we need to extend the libgcc.map function to allow people to insert
$(FPBIT_FUNCS) and such into the map so libgcc_s.so exports these suckers ?
-mike
signature.asc
Description: This is a digitally signed message part.
