softfloat symbol visibility in libgcc.a/libgcc_s.so (fp-bit/dp-bit)

[Mike Frysinger <vapier at gentoo dot org>]

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

Attachment: signature.asc
Description: This is a digitally signed message part.