On Wed, Sep 03, 2003 at 18:37:55 +0100, Ben Harris wrote:

> In article <20030903165140.GE24810@snark.ptc.spbu.ru> you write:
> 
> > PS: While we are at the topic of libc vs. libgcc why do we have our
> > own softfloat in libc and also have gcc's softfloat in libgcc?
> 
> As far as I know, libgcc only provides routines for converting between
> floating-point types and uint64, int64, and uint32 types, all of which
> ultimately seem to end up being implemented using __fix*fsi().  libc then
> provides that, along with all the actual floating-point arithmetic code.
> 
> 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.

I really have no clue about it, but there are some observations I
made recently:

. there are certain symbols that both libgcc and libc define


. doing:

    $ /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)


. 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)
collect2: ld returned 1 exit status
*** Error code 1

Stop.
nbmake: stopped in /nb/src/gnu/usr.bin/binutils/gprof


PS: I'm not subscribed to tech-toolchain, so please keep me on Cc for
this thread.

SY, Uwe
-- 
uwe@ptc.spbu.ru                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen