MIPS: link error against __unpack_d with --enable-target-optspace

Logged here so we can discuss it. Probably upstream and needs to be bounced there.

Reported by PaulFertser on IRC:
 http://irclogs.linaro.org/2011/11/20/%23linaro.html

When building a program that uses double precision software floating point, linking fails with a missing reference to __unpack_d. This is a internal function used to split the floating point number into components when processing.

Most functions such as __muldf3 end up being resolved in libgcc_so.1. At least __ledf2 and __gtdf2 aren't and get pulled in from libgcc.a instead. GCC is configured with --enable-target-optspace, causing libgcc to be built with -Os, causing unpack_d() to not be inlined. libgcc.a doesn't contain a _unpack_d.o so the link fails.

Adding a -shared-libgcc works around the problem as for some reason libgcc_s.so.1 contains a copy of __unpack_d.

I imagine adding a -static-libgcc would cause all functions to break.

This may be related to __ledf2 and __gtdf2 being versioned where __muldf3 etc aren't.

The fault doesn't occur on arm-none-eabi with --enable-target-optspace. libgcc.a doesn't contain any references to unpack_d.

Links:

List of symbols from libgcc_s.so.1:
 http://paste.debian.net/plain/146425

Disassembly of libgcc_s.so.1 showing presence of _unpack_d:
 http://paulfertser.info/libgcc_s-objdump.txt

nm of libgcc.a showing links to unpack_d but no unpack_d itself:
 http://paste.debian.net/plain/146422

objdump of the 'bad' default configuration showing linked in copies of __ledf2 that call unpack_d:
 http://paulfertser.info/radvd-objdump-bad.txt

objdump of the 'good' version with -shared-libgcc showing links to the versioned __ledf2@@GCC_3.0:
 http://paulfertser.info/radvd-objdump-good.txt

Command line used during the link:
 http://paste.debian.net/146420/