Problems compiling . soft-float

Problems compiling . soft-float

[Carlo Agostini]

Hi  All

Just to introduce the problem, here is a summary of what I have done.
I work on an Linux port on an MIPS tx39(R3000) based hardware without
hw floating point support .
I finally managed to compile the glibc 2.2.5 for an mipstx39el-linux
configuration for 2.2.14 Kernel .

I'm working on a Pentium III PC with RedHat7.1

I used binutils 2.11.2 and gcc 3.0.3

The parameters I have used for configuration were the following:

---- configure glibc-2.2.5 ----

configure --host=mipsel-linux\
       --target=mipstx39el-linux\
--enable-add-ons\
--build=i686-pc-linux-gnu\
--prefix=$PREFIX \
--without-fp -v

I first generated a glibc (just typing make, with the default
Makefiles).
..... problem, it seems that the --without-fp has not the expected
effects.

I am trying to port microwindows on an mips tx39

Then, I tried to pass explicitly -msoft-float to gcc as an argument
.....

 mipstx39el-linux-gcc -v  -I/utenti/agostini/prova/mw/src/include
-msoft-float -Wall -O3 -s  -L/utenti/agostini/prova/mw/src/lib  -o
/utenti/agostini/prova/mw/src/bin/nano-X srvmain.o srvfunc.o srvutil.o
srvevent.o srvclip.o srvnet.o
/utenti/agostini/prova/mw/src/lib/libmwengine.a
/utenti/agostini/prova/mw/src/lib/libmwdrivers.a
/utenti/agostini/prova/mw/src/lib/libmwfonts.a
-L/utenti/agostini/prova/mw/src/lib
Reading specs from
/utenti/agostini/mipstx39-linux/lib/gcc-lib/mipstx39el-linux/3.0.3/specs

Configured with: ../../gcc-3.0.3/configure
--with-gcc-version-trigger=/utenti/agostini/mipstx39-linux/src/gcc-3.0.3/gcc/version.c

--host=i686-pc-linux-gnu --prefix=/utenti/agostini/mipstx39-linux
--target=mipstx39el-linux --with-gnu-ld --with-gnu-as --disable-shared
--enable-languages=c -v
Thread model: single
gcc version 3.0.3
 /utenti/agostini/mipstx39-linux/lib/gcc-lib/mipstx39el-linux/3.0.3/collect2

-EL -dynamic-linker /lib/ld.so.1 -o
/utenti/agostini/prova/mw/src/bin/nano-X -s
/utenti/agostini/mipstx39-linux/lib/gcc-lib/mipstx39el-linux/3.0.3/../../../../mipstx39el-linux/lib/crt1.o

/utenti/agostini/mipstx39-linux/lib/gcc-lib/mipstx39el-linux/3.0.3/../../../../mipstx39el-linux/lib/crti.o

/utenti/agostini/mipstx39-linux/lib/gcc-lib/mipstx39el-linux/3.0.3/crtbegin.o

-L/utenti/agostini/prova/mw/src/lib -L/utenti/agostini/prova/mw/src/lib
-L/utenti/agostini/mipstx39-linux/lib/gcc-lib/mipstx39el-linux/3.0.3
-L/utenti/agostini/mipstx39-linux/lib/gcc-lib/mipstx39el-linux/3.0.3/../../../../mipstx39el-linux/lib

srvmain.o srvfunc.o srvutil.o srvevent.o srvclip.o srvnet.o
/utenti/agostini/prova/mw/src/lib/libmwengine.a
/utenti/agostini/prova/mw/src/lib/libmwdrivers.a
/utenti/agostini/prova/mw/src/lib/libmwfonts.a -lgcc -lc -lgcc
/utenti/agostini/mipstx39-linux/lib/gcc-lib/mipstx39el-linux/3.0.3/crtend.o

/utenti/agostini/mipstx39-linux/lib/gcc-lib/mipstx39el-linux/3.0.3/../../../../mipstx39el-linux/lib/crtn.o

/utenti/agostini/prova/mw/src/lib/libmwengine.a(devarc.o): In function
`qcos':
devarc.o(.text+0x28): undefined reference to `fptosi'
devarc.o(.text+0x4c): undefined reference to `sitofp'
devarc.o(.text+0x64): undefined reference to `fpsub'
devarc.o(.text+0x104): undefined reference to `fpmul'
devarc.o(.text+0x11c): undefined reference to `fpadd'
devarc.o(.text+0x164): undefined reference to `fpmul'
devarc.o(.text+0x18c): undefined reference to `fpsub'
devarc.o(.text+0x1d4): undefined reference to `fpmul'
devarc.o(.text+0x1ec): undefined reference to `fpsub'
devarc.o(.text+0x220): undefined reference to `fpmul'
devarc.o(.text+0x238): undefined reference to `fpadd'
devarc.o(.text+0x250): undefined reference to `fpsub'
devarc.o(.text+0x268): undefined reference to `sitofp'
devarc.o(.text+0x280): undefined reference to `fpsub'
/utenti/agostini/prova/mw/src/lib/libmwengine.a(devarc.o): In function
`qsin':
devarc.o(.text+0x2cc): undefined reference to `fptosi'
devarc.o(.text+0x2f4): undefined reference to `sitofp'
devarc.o(.text+0x30c): undefined reference to `fpsub'
devarc.o(.text+0x3ac): undefined reference to `fpmul'
devarc.o(.text+0x3c4): undefined reference to `fpadd'
devarc.o(.text+0x40c): undefined reference to `fpmul'
devarc.o(.text+0x434): undefined reference to `fpsub'
devarc.o(.text+0x47c): undefined reference to `fpmul'
devarc.o(.text+0x494): undefined reference to `fpsub'
devarc.o(.text+0x4c8): undefined reference to `fpmul'
devarc.o(.text+0x4e0): undefined reference to `fpadd'
devarc.o(.text+0x4f8): undefined reference to `fpsub'
devarc.o(.text+0x510): undefined reference to `sitofp'
devarc.o(.text+0x528): undefined reference to `fpsub'
/utenti/agostini/prova/mw/src/lib/libmwengine.a(devarc.o): In function
`GdArcAngle':
devarc.o(.text+0xc14): undefined reference to `litodp'
devarc.o(.text+0xc34): undefined reference to `dpmul'
devarc.o(.text+0xc4c): undefined reference to `dptofp'
devarc.o(.text+0xc84): undefined reference to `sitofp'
devarc.o(.text+0xca0): undefined reference to `fpmul'
devarc.o(.text+0xcb4): undefined reference to `fptosi'
devarc.o(.text+0xccc): undefined reference to `litodp'
devarc.o(.text+0xcec): undefined reference to `dpmul'
devarc.o(.text+0xd04): undefined reference to `dptofp'
devarc.o(.text+0xd3c): undefined reference to `fpmul'
devarc.o(.text+0xd50): undefined reference to `fptosi'
devarc.o(.text+0xd8c): undefined reference to `fpsub'
devarc.o(.text+0xdc4): undefined reference to `fpsub'
devarc.o(.text+0xddc): undefined reference to `sitofp'
devarc.o(.text+0xdf8): undefined reference to `fpmul'
devarc.o(.text+0xe0c): undefined reference to `fptosi'
devarc.o(.text+0xe28): undefined reference to `fpmul'
devarc.o(.text+0xe3c): undefined reference to `fptosi'
/utenti/agostini/mipstx39-linux/lib/libc.so.6: undefined reference to
`no symbol'
collect2: ld returned 1 exit status

Has anyone information about this problem ?

Does anyone know where could I find a set of
floating-point instructions library ?

you can help me ?

Thanking you in advance

Carlo.

Re: Problems compiling . soft-float

[Ralf Baechle]

On Mon, Feb 25, 2002 at 08:19:36AM +0100, Carlo Agostini wrote:

> Then, I tried to pass explicitly -msoft-float to gcc as an argument
> .....

Not supported.  Use the kernel fp emulation.

  Ralf

Re: Problems compiling . soft-float

[Jay Carlson]

On Monday, February 25, 2002, at 07:25 AM, Ralf Baechle wrote:

> On Mon, Feb 25, 2002 at 08:19:36AM +0100, Carlo Agostini wrote:

[link fails due to missing "dpmul", "dpadd", etc.]

>
>> Then, I tried to pass explicitly -msoft-float to gcc as an argument
>> .....
>
> Not supported.  Use the kernel fp emulation.

This works fine if you undo the mistake in gcc/config/mips/t-linux, or 
in elf.h, your choice.

The default on MIPS is for gcc to use the GOFAST style of soft-float 
calls.  gcc/config/mips/elf.h sets this up via #include "gofast.h".

Now, t-linux *does* include the right goo to get all the software 
floating point emulation code compiled into libgcc.a.  But it's 
defaulting not to the GNU style but to the GOFAST style calls:

         echo '#undef US_SOFTWARE_GOFAST' >> dp-bit.c

So everything works if we just make the two consistent.   The old(er) 
Agenda toolchain takes the position that "every other gcc MIPS target 
uses GOFAST, so should we"; you can just change that #undef to #define.

But I (now) think the better path is to stick to the GNU-style softfloat 
calls,  Unless you want to modify elf.h, the best you can do is undo the 
#include "gofast.h" damage in linux.h.  Near the end:

+/* undo the effects of elf.h including gofast.h */
+#undef US_SOFTWARE_GOFAST
+#undef INIT_GOFAST_OPTABS
+#define INIT_GOFAST_OPTABS
+
+#undef GOFAST_CLEAR_NEG_FLOAT_OPTAB
+#undef GOFAST_RENAME_LIBCALLS

This of course requires knowledge of what exactly gofast.h did, so it's 
not optimal either.

Ralf is right that the kernel emulator is the supported route.  But if 
you're willing to go to the trouble of building everything from scratch, 
this does work.

Jay

Re: Problems compiling . soft-float

[Ralf Baechle]

On Mon, Feb 25, 2002 at 11:47:44PM -0500, Jay Carlson wrote:

> Ralf is right that the kernel emulator is the supported route.  But if 
> you're willing to go to the trouble of building everything from scratch, 
> this does work.

It's really a major pain.  Softfp isn't defined in the ABI which assumes
an FPU is available.  As the result there is no provision for mixing
softfp and fp-less code.

Something for the binutils to-do list - ld should make mixing hard-fp
and soft-fp binaries impossible.

  Ralf

Re: Problems compiling . soft-float

[Daniel Jacobowitz]

On Tue, Feb 26, 2002 at 06:02:37AM +0100, Ralf Baechle wrote:
> On Mon, Feb 25, 2002 at 11:47:44PM -0500, Jay Carlson wrote:
> 
> > Ralf is right that the kernel emulator is the supported route.  But if 
> > you're willing to go to the trouble of building everything from scratch, 
> > this does work.
> 
> It's really a major pain.  Softfp isn't defined in the ABI which assumes
> an FPU is available.  As the result there is no provision for mixing
> softfp and fp-less code.
> 
> Something for the binutils to-do list - ld should make mixing hard-fp
> and soft-fp binaries impossible.

Or we could see if it is possible to define the ABIs in such a way that
they can call each other... I don't immediately see a problem.  The
only code that will clobber FP registers is FP code.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Problems compiling . soft-float

[Jay Carlson]

On Tuesday, February 26, 2002, at 12:10 AM, Daniel Jacobowitz wrote:

> On Tue, Feb 26, 2002 at 06:02:37AM +0100, Ralf Baechle wrote:
>> On Mon, Feb 25, 2002 at 11:47:44PM -0500, Jay Carlson wrote:
>>
>>> Ralf is right that the kernel emulator is the supported route.  But if
>>> you're willing to go to the trouble of building everything from 
>>> scratch,
>>> this does work.
>>
>> It's really a major pain.  Softfp isn't defined in the ABI which 
>> assumes
>> an FPU is available.  As the result there is no provision for mixing
>> softfp and fp-less code.
>>
>> Something for the binutils to-do list - ld should make mixing hard-fp
>> and soft-fp binaries impossible.
>
> Or we could see if it is possible to define the ABIs in such a way that
> they can call each other... I don't immediately see a problem.  The
> only code that will clobber FP registers is FP code.

Oh, they can intercall without any error until you call sin(1.0), at 
which point one side's calling convention places 1.0 in integer 
registers and the other places it in fp registers.  Lots of fun to debug 
this one, especially once you have a kernel emulator that won't SIGILL 
for the hardfp ops :-)  Seriously, this was a common screwup in the 
Agenda world until the snow specs file.

Jay

Re: Problems compiling . soft-float

[Jay Carlson]

On Tuesday, February 26, 2002, at 12:02 AM, Ralf Baechle wrote:

> Something for the binutils to-do list - ld should make mixing hard-fp
> and soft-fp binaries impossible.

Agreed.  So do we need a special flag/directive for gas to say "I'm 
using soft float"?

Jay

Re: Problems compiling . soft-float

[Daniel Jacobowitz]

On Tue, Feb 26, 2002 at 12:28:52AM -0500, Jay Carlson wrote:
> 
> On Tuesday, February 26, 2002, at 12:02 AM, Ralf Baechle wrote:
> 
> >Something for the binutils to-do list - ld should make mixing hard-fp
> >and soft-fp binaries impossible.
> 
> Agreed.  So do we need a special flag/directive for gas to say "I'm 
> using soft float"?

And bit in the ELF header.  We can talk about this in a couple weeks
once binutils 2.12 is out :)

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Problems compiling . soft-float

[Dominic Sweetman]

Ralf,

> It's really a major pain.  Softfp isn't defined in the ABI which assumes
> an FPU is available.  As the result there is no provision for mixing
> softfp and fp-less code.
> 
> Something for the binutils to-do list - ld should make mixing hard-fp
> and soft-fp binaries impossible.

Incremental changes to the ABI are pretty bad news.  Isn't it
avoidable in this case?

It seems to me that soft-float programs are either carefully
controlled test cases, or used as part of a 100% soft-float system.

In the first case the programmer had better take care, and in the
second the kernel should have been changed to kill any program with an
FP op-code.

-- 
Dominic Sweetman
Algorithmics Ltd
The Fruit Farm, Ely Road, Chittering, CAMBS CB5 9PH, ENGLAND
phone +44 1223 706200/fax +44 1223 706250/direct +44 1223 706205
http://www.algor.co.uk

Re: Problems compiling . soft-float

[Ralf Baechle]

On Tue, Feb 26, 2002 at 10:55:17AM +0000, Dominic Sweetman wrote:

> Incremental changes to the ABI are pretty bad news.  Isn't it
> avoidable in this case?
> 
> It seems to me that soft-float programs are either carefully
> controlled test cases, or used as part of a 100% soft-float system.
> 
> In the first case the programmer had better take care, and in the
> second the kernel should have been changed to kill any program with an
> FP op-code.

Experience shows that people will use every opportunity to shot themselfes
into their foot ...

Even a soft-fp system may still have the in-kernel emulator, so be able to
execute both soft-fp and hard-fp binaries correctly.  But it won't be able
to support a mix of both nor would the kernel know that an application is
just mixing hard and soft fp.

  Ralf

Re: Problems compiling . soft-float

[Maciej W. Rozycki]

On Tue, 26 Feb 2002, Daniel Jacobowitz wrote:

> > Agreed.  So do we need a special flag/directive for gas to say "I'm 
> > using soft float"?
> 
> And bit in the ELF header.  We can talk about this in a couple weeks
> once binutils 2.12 is out :)

 And a way for an override for ones who know what they are doing. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: Problems compiling . soft-float

[Maciej W. Rozycki]

On Tue, 26 Feb 2002, Daniel Jacobowitz wrote:

> > Agreed.  So do we need a special flag/directive for gas to say "I'm 
> > using soft float"?
> 
> And bit in the ELF header.  We can talk about this in a couple weeks
> once binutils 2.12 is out :)

 And a way for an override for ones who know what they are doing. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +