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
signature.asc
Description: This is a digitally signed message part.
