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

[Mike Frysinger <vapier at gentoo dot org>]

On Tuesday 10 March 2009 22:55:12 Joseph S. Myers wrote:
> On Tue, 10 Mar 2009, Mike Frysinger wrote:
> > On Tuesday 10 March 2009 21:44:23 Joseph S. Myers wrote:
> > > On Tue, 10 Mar 2009, Mike Frysinger wrote:
> > > > 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 ?
> > >
> > > Exporting functions that are internal to fp-bit rather than part of the
> > > documented libgcc interface has the disadvantage that you then need to
> > > keep them around when targets change to other software floating-point
> > > implementations (such as soft-fp, which is significantly faster than
> > > fp-bit, or assembly implementations for particular targets).
> > >
> > > Perhaps you might like to convert your target to soft-fp to avoid the
> > > problem.  fp-bit has slightly smaller code size and supports 16-bit
> > > targets which soft-fp may not, but for any 32-bit or 64-bit target a
> > > few kB more in libgcc shouldn't be significant and the speed
> > > improvements are substantial.  (If you want exception and rounding mode
> > > support for software floating-point, soft-fp can do that as well, but
> > > you can also configure it with that support disabled.)
> >
> > you're saying the ABI of soft-fp is stable and is part of the export
> > libgcc_s.so interface ?
>
> Yes.
>
> Both fp-bit and soft-fp provide functions documented under "Soft float
> library routines" in libgcc.texi.  These are part of the public exported
> libgcc_s.so interface.
>
> Some such functions are also provided by libgcc2.c.  fp-bit does not
> provide those; soft-fp can but doesn't have to, depending on the setting
> of softfp_exclude_libgcc2.  (You want softfp_exclude_libgcc2 := n, unless
> you have both hard-float and soft-float multilibs, when setting it to y
> avoids hard-float multilibs using soft-fp implementations of these
> functions.  The soft-fp implementations are expected to be better for
> soft-float (the operations can be carried out directly rather than
> wrapping other operations), but worse for hard-float (wrapping a related
> hard-float operation is better than implementing it all in soft-float).)
>
> soft-fp does not have any functions other than those forming part of the
> libgcc interface; everything is inlined in those functions.  fp-bit has a
> number of internal helper functions built into separate objects.  It's
> these helper functions you were seeing exported only from the static
> libgcc, as hidden functions.  Because they are not part of the libgcc
> interface they should not be exported from the shared libgcc.  I don't
> know why shared libraries linked with the shared libgcc should get hidden
> copies of these from the static libgcc (especially since I didn't think we
> linked shared libraries with static libgcc at all at present - this is a
> bug, they do sometimes need to be able to get static-only symbols from
> libgcc).  C executables link with static libgcc by default rather than
> shared libgcc.

that sounds great.  considering the Blackfin processor is a 32bit proc, it 
seems like a no brainer to convert over to soft-fp.  it would certainly 
address the symbol bloat that i see with fp-bit today.  even if soft-fp is a 
little bit bigger, it sounds like that would quickly be made up by having the 
functions always be part of libgcc_s.so rather than creeping into everything 
else.
-mike

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