MIPS: link error against __unpack_d with --enable-target-optspace
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Linaro GCC |
Won't Fix
|
Undecided
|
Michael Collison |
Bug Description
Logged here so we can discuss it. Probably upstream and needs to be bounced there.
Reported by PaulFertser on IRC:
http://
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-
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-
Links:
List of symbols from libgcc_s.so.1:
http://
Disassembly of libgcc_s.so.1 showing presence of _unpack_d:
http://
nm of libgcc.a showing links to unpack_d but no unpack_d itself:
http://
objdump of the 'bad' default configuration showing linked in copies of __ledf2 that call unpack_d:
http://
objdump of the 'good' version with -shared-libgcc showing links to the versioned __ledf2@@GCC_3.0:
http://
Command line used during the link:
http://
...and this doesn't happen on ARM as we have hand-coded assembly versions in ieee754-df.s.