[ Please excuse the slowness of this reply.  I've been busy, and this libgcc
  stuff frankly scares me.  Also please excuse the lack of lucidity in my
  writing.  I don't understand this stuff well enough to write clearly about
  it. ]

In article <20030903183437.GG24810@snark.ptc.spbu.ru> you write:
>On Wed, Sep 03, 2003 at 18:37:55 +0100, Ben Harris wrote:
>> It would probably be faster and more accurate to use the SoftFloat code
>> directly for everything (and for sqrt() too), but I've never got round to
>> working out how to do this without breaking everything.
>
>    $ /usr/nb3/tools/bin/shle--netbsdelf-nm libc.so | grep 'U '
>  
>  shows that __fixunsdfsi is undefined (my understanding is that the
>  intent was to have only '__progname' and 'environ' undefined in
>  libc.so)

That's my understanding too.

>. when I tried to build sh3 libc with -DSOFTFLOAT_NEED_FIXUNS
>  I've got linkage conflicts while building gprof
>
>/usr/nb/distrib/hpcsh/usr/lib/libc.a(softfloat.o): In function `__fixunsdfsi':
>softfloat.o(.text+0x257c): multiple definition of `__fixunsdfsi'
>/usr/nb/distrib/hpcsh/usr/lib/libgcc.a(_fixunsdfsi.o)(.text+0x0): first defined here
>/usr/nb/tools/shle--netbsdelf/bin/ld: Warning: size of symbol `__fixunsdfsi' changed from 100 to 220 in /usr/nb/distrib/hpcsh/usr/lib/libc.a(softfloat.o)

So that considers that libgcc version to be "first", and then explodes on
the libc one.  As I understand it, the tail of the linker invocation goes
something like "-lc -lgcc -lc", so what's happened here is that the main
program hasn't needed softfloat.o at all, then something in libgcc needed
__fixunsdfsi(), which it got from libgcc, but something else in libgcc
needed something from softfloat.o that _wasn't_ also in libgcc, so that got
softfloat.o included, which gave us the conflict.

This could be solved by arranging to split up softfloat.o into a separate
object for each public symbol, with shared functions being separate again. 
A simple way to achieve this would be to simply wrap all the SoftFloat
functions, as is already done for the comparisons, rather than renaming
them.

I don't really like this idea, though, because it means that we still have
functions in libc and libgcc with the same name, and which one gets used
depends on whether anyone's asked for it before libgcc.  On the other hand,
this already happens for some of the quad code in libc -- for instance both
libc and libgcc have implementations of __muldi3.

Thus, I think that while the best solution would be to have libgcc not
include those functions that we can provide in libc, it'd be acceptable to
arrange for all the duplicated functions to be in their own objects in libc
so that they won't get included unless they're really needed.  I'd do this
by adding small wrappers along the lines of the existing ones for comparison
operators, since teasing out softfloat.c into its component parts looks like
rather too much work (especially if we ever want to merge in upstream
fixes).

-- 
Ben Harris                                                   <bjh21@NetBSD.org>
Portmaster, NetBSD/acorn26           <URL:http://www.NetBSD.org/Ports/acorn26/>