[uClibc]-msoft-float questions

[Jay Carlson]

I apologize if I'm getting the details wrong below.  I don't have access to
my Linux boxes, no uclibc source tree here, and I may be misunderstanding
something about The Righteous Way to do any of this.  OTOH, we went through
this on linuxce on mips and did OK.

"Erik Andersen" <andersen at codepoet.org> writes:

> On Mon May 06, 2002 at 06:08:49PM -0400, Kyle Harris wrote:
> > Hi,
> >
> > I'm trying to build an application with arm-uclibc-gcc. I'm using the
> > -msoft-float compiler option. During the link phase I get lots of errors
> > similar to:
> >
> > undefined reference to `__muldf3`
> >
> > I noticed uclibc is built without -msoft-float, but attempting to build
this
> > way also fails. Can someone tell what I need to do to support a
processor
> > without an FPU?
>
> Build uClibc with HAS_FLOATING_POINT=false and that should do it,

That builds uClibc such that it doesn't use floating point at all.  But if
you do want C floating point and you don't want to use a kernel FP hardware
emulator, you want to build *everything* with -msoft-float.  On most
processors, -msoft-float is an incompatible ABI, where floats and doubles
are passed in integer registers, so you have to be very careful about this.
For linuxce, I almost put "The name of the compiler is
CC='mipsel-linux-gcc -msoft-float'" in my signature, since I said it so much
:-)

-msoft-float assumes that somewhere in the linktime environment are
functions named stuff like __muldf3 that implement floating point ops
(passing and returning values in integer registers, of course).  As of a few
years ago, gcc includes a generic implementation of these functions in
dp-bit.c and fp-bit.c, which can be built into libgcc.a by goo in the
target-specific makefile fragement.  Look around the gcc/config/*/t-* for
examples of how to do this, as it varies a little depending on gcc version.

If you're building other libraries during the gcc build process (like
libstdc++) you'll want them to be built as -msoft-float as well.  There are
two reasonable ways to do this.

1) Hack up the gcc/config/arm/t-linux and gcc/config/arm/linux.h to *always*
build -msoft-float.  Can lead to confusion if you don't keep it separated
from the "standard" config, so maybe you're better off making it configure
as arm-sfp-linux or something.  (Haven't seen how much that will break yet;
I'll be trying it soon for snow.)

2) I've been using multilibs, where gcc builds different library variants
and chooses the proper ones for linktime based on the flags used.  A link
with mipsel-linux-gcc -msoft-float would still use libraries and start files
from gcc-lib/whatever/this/stuff/is/ but prefer
gcc-lib/whatever/this/stuff/is/soft-float/ .  The advantage of this is that
a single compiler can support all ABI variants.

If you're using static linking, you're mostly done.  But if you're
dynamically linking, you'll have to decide where you want the libgcc.a
[fd]p-bit math functions to end up.  I took the lazy way on linuxce and just
let them stay in libgcc.a, which gets statically linked into almost
everything, bloating every binary by 8k or so.  gcc 3.0 wants a shared
libgcc.so (right?) so that's decided for you there.

By the way, uclibc's gcc wrapper can't handle
CC='foobar-linux-gcc -Badditional -m-options'....

Jay