Subject: MIPS SF toolchain

From: Matej Kupljen <[email-masked]>
Date: Wed, 07 Sep 2005 15:09:44 +0200

Hi

Can somebody tell me, what is the right way to make a soft float
toolchain. I tried with crosstool with different flags for configure
and gcc, but the resulting binaries still contains the FP instructions, 
like swc1.

I used --with-float=soft and --nfp for gcc configure,
--without-fp for glibc configure, and compiled glibc
with -msoft-float flag.

Am I missing something, or am I using the wrong flags?

GCC: 3.3.5
GLIBC: 2.3.5
BINUTILS: 2.15

BR,
Matej

---

From: [email-masked]
Date: Wed, 7 Sep 2005 08:54:28 -0500 (CDT)

> and gcc, but the resulting binaries still contains the FP instructions, 
Here are my RPMS and SRPMS for soft float MIPS toolchains. They are a
bit old, but you can at least see the detailed steps necessary to do
it properly. These use uClibc and not glibc however.

-Steve

ftp://ftp.realitydiluted.com/linux/MIPS/toolchains/uclibc-swfp/

---

From: David Daney <[email-masked]>
Date: Wed, 07 Sep 2005 08:33:36 -0700

> Am I missing something, or am I using the wrong flags?

On gcc 3.3.x --with-float=soft does nothing.  If you are using a MIPS32 
ISA processor you can configure it with --target=mipsisa32[el]-linux to 
get soft float and MIPS32 ISA by default.

But even better would be to use gcc 3.4.x or 4.0.x where 
--with-float=soft works.  I would also recommend binutils 2.16.1 or 
above as there are some severe bugs in the mips linker in earlier versions.

David Daney.

---

From: Matej Kupljen <[email-masked]>
Date: Thu, 08 Sep 2005 10:41:06 +0200

Hi

> get soft float and MIPS32 ISA by default.

O.K.
Thank you for the explanation.

> above as there are some severe bugs in the mips linker in earlier versions.

O.K.
Yesterday I tried with the gcc 3.4.3, glibc 2.3.5 and binutils 2.16.1.
libgcc.a looks O.K, because I did not find any FP instruction, however
if I do objdump on libc.so.6, I get:

0002ff70 <__sigsetjmp_aux>:
   2ff70:       3c1c0017        lui     gp,0x17
   2ff74:       279cce30        addiu   gp,gp,-12752
   2ff78:       0399e021        addu    gp,gp,t9
   2ff7c:       00801021        move    v0,a0
   2ff80:       e4940038        swc1    $f20,56(a0)
   2ff84:       e495003c        swc1    $f21,60(a0)
   2ff88:       e4960040        swc1    $f22,64(a0)
   2ff8c:       e4970044        swc1    $f23,68(a0)
   2ff90:       e4980048        swc1    $f24,72(a0)
   2ff94:       e499004c        swc1    $f25,76(a0)
   2ff98:       e49a0050        swc1    $f26,80(a0)
   2ff9c:       e49b0054        swc1    $f27,84(a0)
   2ffa0:       e49c0058        swc1    $f28,88(a0)
   2ffa4:       e49d005c        swc1    $f29,92(a0)
   2ffa8:       e49e0060        swc1    $f30,96(a0)
   2ffac:       e49f0064        swc1    $f31,100(a0)
   2ffb0:       ac9f0000        sw      ra,0(a0)
   2ffb4:       ac860004        sw      a2,4(a0)
   2ffb8:       ac870028        sw      a3,40(a0)

Again, FP instructions! I don't know what is wrong :-(

Now I am trying with the:
GCC: 4.1.0
GLIBC: 2.3.5
BINUTILS: 2.16.1
Linux Headers: 2.6.11

Will let you know, when the toolchain is built.

BR,
Matej

P.S.: I am cc-ing crosstool mailing list too.

---

From: Matej Kupljen <[email-masked]>
Date: Thu, 08 Sep 2005 13:33:19 +0200

Hi

> Now I am trying with the:

Here are the results:
ligcc.a does not have any sf instructions.
busybox built as dynamic binary does not have any sf ins.
libc.so.6 has this:

-------------------------------------------------------------
0002fe80 <__longjmp>:
   2fe80:       c4940038        lwc1    $f20,56(a0)
   2fe84:       c495003c        lwc1    $f21,60(a0)
   2fe88:       c4960040        lwc1    $f22,64(a0)
   2fe8c:       c4970044        lwc1    $f23,68(a0)
   2fe90:       c4980048        lwc1    $f24,72(a0)
   2fe94:       c499004c        lwc1    $f25,76(a0)
   2fe98:       c49a0050        lwc1    $f26,80(a0)
   2fe9c:       c49b0054        lwc1    $f27,84(a0)
   2fea0:       c49c0058        lwc1    $f28,88(a0)
   2fea4:       c49d005c        lwc1    $f29,92(a0)
   2fea8:       c49e0060        lwc1    $f30,96(a0)
   2feac:       c49f0064        lwc1    $f31,100(a0)
   2feb0:       8c820030        lw      v0,48(a0)
   2feb4:       00000000        nop
   2feb8:       44c2f800        ctc1    v0,$31
   2febc:       8c9c002c        lw      gp,44(a0)
   2fec0:       8c900008        lw      s0,8(a0)
   2fec4:       8c91000c        lw      s1,12(a0)
   2fec8:       8c920010        lw      s2,16(a0)
   2fecc:       8c930014        lw      s3,20(a0)
   2fed0:       8c940018        lw      s4,24(a0)
   2fed4:       8c95001c        lw      s5,28(a0)
   2fed8:       8c960020        lw      s6,32(a0)
   2fedc:       8c970024        lw      s7,36(a0)
   2fee0:       8c990000        lw      t9,0(a0)
   2fee4:       8c9d0004        lw      sp,4(a0)
   2fee8:       8c9e0028        lw      s8,40(a0)
   2feec:       14a00005        bnez    a1,2ff04 <__longjmp+0x84>
   2fef0:       00000000        nop
   2fef4:       03200008        jr      t9
   2fef8:       24020001        li      v0,1
   2fefc:       1000ffff        b       2fefc <__longjmp+0x7c>
   2ff00:       00000000        nop
   2ff04:       03200008        jr      t9
   2ff08:       00a01021        move    v0,a1
   2ff0c:       1000fffb        b       2fefc <__longjmp+0x7c>
   2ff10:       00000000        nop
-------------------------------------------------------------
and
-------------------------------------------------------------
0002ff70 <__sigsetjmp_aux>:
   2ff70:       3c1c0017        lui     gp,0x17
   2ff74:       279cce40        addiu   gp,gp,-12736
   2ff78:       0399e021        addu    gp,gp,t9
   2ff7c:       00801021        move    v0,a0
   2ff80:       e4940038        swc1    $f20,56(a0)
   2ff84:       e495003c        swc1    $f21,60(a0)
   2ff88:       e4960040        swc1    $f22,64(a0)
   2ff8c:       e4970044        swc1    $f23,68(a0)
   2ff90:       e4980048        swc1    $f24,72(a0)
   2ff94:       e499004c        swc1    $f25,76(a0)
   2ff98:       e49a0050        swc1    $f26,80(a0)
   2ff9c:       e49b0054        swc1    $f27,84(a0)
   2ffa0:       e49c0058        swc1    $f28,88(a0)
   2ffa4:       e49d005c        swc1    $f29,92(a0)
   2ffa8:       e49e0060        swc1    $f30,96(a0)
   2ffac:       e49f0064        swc1    $f31,100(a0)
   2ffb0:       ac9f0000        sw      ra,0(a0)
   2ffb4:       ac860004        sw      a2,4(a0)
   2ffb8:       ac870028        sw      a3,40(a0)
   2ffbc:       ac9c002c        sw      gp,44(a0)
   2ffc0:       ac900008        sw      s0,8(a0)
   2ffc4:       ac91000c        sw      s1,12(a0)
   2ffc8:       ac920010        sw      s2,16(a0)
   2ffcc:       ac930014        sw      s3,20(a0)
   2ffd0:       ac940018        sw      s4,24(a0)
   2ffd4:       ac95001c        sw      s5,28(a0)
   2ffd8:       ac960020        sw      s6,32(a0)
   2ffdc:       ac970024        sw      s7,36(a0)
   2ffe0:       8f9982a8        lw      t9,-32088(gp)
   2ffe4:       4443f800        cfc1    v1,$31
   2ffe8:       03200008        jr      t9
   2ffec:       ac430030        sw      v1,48(v0)
-------------------------------------------------------------

I did:
mipsel-linux-objdump -S libc.so.6 | less 
and then searching for $f (floating point registers)

If I link busybox static, I get those two functions linked in.

How to solve this?

One more thing.
I can compile strace only with gcc-3.3.4. With any other version
I get:
syscall.c:449: error: 'SYS_read' undeclared (first use in this function)

I applayed the patch for this, but it doesn't seem to help.

BR,
Matej

---

From: Matej Kupljen <[email-masked]>
Date: Thu, 08 Sep 2005 14:22:02 +0200

Hi

I think I found the problem.

....

This code is written in  sysdeps/mips/setjmp_aux.c in 
inline assembly.

> and

This code is written in sysdeps/mips/__longjmp.c in 
inline assembly.

> How to solve this?

Because I am using sf, there is no need to store those
registers, or is it?
Can I just #ifdef this code if compiled for sf?

BR,
Matej

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 8 Sep 2005 13:29:33 +0100

> Can I just #ifdef this code if compiled for sf?

Why not just letting the kernel fp emulator do the job?  On the average
fpu-less system fp performance doesn't matter, so the impact of the
kernel fp emulator is much less than the pain of avoiding it.

  Ralf

---

From: Dan Kegel <[email-masked]>
Date: Thu, 08 Sep 2005 06:48:19 -0700

Matej Kupljen wrote:
> inline assembly.  ...

Other architectures do things like this, e.g.

sysdeps/powerpc/powerpc32/__longjmp-common.S:#ifdef __NO_VMX__

so I don't see why not.

In fact, I had to do something similar once to make life
possible for ppc405.  See

http://kegel.com/xgcc3/glibc-ppc-nofpu.patch3

(Hmm, wonder if something like that ever made it in to
mainline glibc.)

- Dan

-- 
Trying to get a job as a c++ developer?  See http://kegel.com/academy/getting-hired.html

---

From: David Daney <[email-masked]>
Date: Thu, 08 Sep 2005 08:29:05 -0700

> Can I just #ifdef this code if compiled for sf?

I do have some patches for glibc to get rid of these in a soft float 
build.  However as Ralf Baechle said in the other message, the kernel FP 
emulator works and is not that large of an overhead.

The reason I did the glibc patch was that some IDT processor/linux 
kernel combination I was using was broken WRT the FP emulator.  I 
suppose if you had a lot of code doing setjump (like C++ code with 
exeception handling that uses setjump/longjump as would be obtained with 
uClibc) than this would be bad.  But since you are using glibc, the 
tools will be using DWARF exception handling and it is not really an issue.

David Daney.

---

From: Matej Kupljen <[email-masked]>
Date: Fri, 09 Sep 2005 08:48:22 +0200

Hi

> build.  

Can I see these patches, please?
(What is the #define for the FP?)

> However as Ralf Baechle said in the other message, the kernel FP 

I also removed the FP Emulator in the kernel, just to be sure that
no SF ins are executed (I can send the patch to the list, but I know
there has already been discussion about this).

IMHO, if we say that we have a SF toolchain then there MUST NOT
BE any SF ins, otherwise we have a "semi soft float" toolchain.
Don't you agree?

BR,
Matej

---

From: David Daney <[email-masked]>
Date: Fri, 09 Sep 2005 08:20:03 -0700

>>emulator works and is not that large of an overhead.

Attached is the portions of my patches to glibc-2.3.3 that contain the 
setjump/longjump hacks.  There are other things in there as well, so you 
will have to pick and choose as to which parts you want.

I did this more as a proof of concept rather than the definitive answer. 
  There are still some FP instructions being generated but I have not 
tracked them down yet.

On my 2.4.29 based kernel (mipsel-linux) with glibc 2.3.3 and busybox 
1.00, I don't get the 'Algorithmics/MIPS FPU Emulator v1.5' message 
until I run ldconfig or ftp.  Most other programs don't seem to run any 
FP instructions.

> BE any SF ins, otherwise we have a "semi soft float" toolchain.

Of course I agree.

David Daney.

---

From: Matej Kupljen <[email-masked]>
Date: Mon, 12 Sep 2005 09:33:58 +0200

Hi

> will have to pick and choose as to which parts you want.

Done that :-)

>   There are still some FP instructions being generated but I have not 

I did. They were in the sysdeps/mips/fpu_control.h
I tested it with busybox and MPlayer and found no SF ins in the
binaries. I run those binaries on kernel which has no FPU emulator.

Versions:
BINUTILS: 2.16.1
GCC:      3.4.4
GLIBC:    2.3.5

Let me know the results, if someone is going to use this patch.

BR,
Matej