This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: softfloat symbol visibility in libgcc.a/libgcc_s.so (fp-bit/dp-bit)
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.
--
Joseph S. Myers
joseph@codesourcery.com