Patch for Soft-Float Problems w/ Glibc & Gcc?

Patch for Soft-Float Problems w/ Glibc & Gcc?

[Grant Erickson]

For some time I've noted but have never bothered chasing down the *printf
problems associated with using -msoft-float/-D_SOFT_FLOAT on Linux/PPC.

Needing to remedy the issue, I started chasing it down using the code
samples below. When compiled using just '$(CROSS_COMPILE)gcc -o pi-test
*.c' everything works fine:

	user@host% ./pi-test
	The value of Pi is approximately: 3.142857

If I turn-around and compile it with '$(CROSS_COMPILE)gcc -o pi-test
-msoft-float *.c' or '$(CROSS_COMPILE)gcc -o pi-test -msoft-float
-D_SOFT_FLOAT *.c' I get:

	user@host% ./pi-test
	The value of Pi is approximately: 0.000000

After disassembling the code, from what I can see both bits of code are
generating the right output for the IEEE single-precision result. Both
bits of code appear to be following the correct register callee/caller
convetions for both 'pi' and 'float_print'. So, I have to assume that the
problem lies somewhere within either the '__extendsfdf2' or 'printf'
subroutine calls within 'float_print':

	Disassembly of section .text:

	00000000 <float_print>:
	   0:   94 21 ff e0     stwu    r1,-32(r1)
	   4:   7c 08 02 a6     mflr    r0
	   8:   93 e1 00 1c     stw     r31,28(r1)
	   c:   90 01 00 24     stw     r0,36(r1)
	  10:   7c 3f 0b 78     mr      r31,r1
	  14:   90 7f 00 08     stw     r3,8(r31)
	  18:   90 9f 00 0c     stw     r4,12(r31)
	  1c:   80 7f 00 0c     lwz     r3,12(r31)
	  20:   48 00 00 01     bl      __extendsfdf2
	  24:   7c 69 1b 78     mr      r9,r3
	  28:   7c 8a 23 78     mr      r10,r4
	  2c:   3d 60 00 00     lis     r11,.rodata@h
	  30:   38 6b 00 00     addi    r3,r11,.rodata@l
	  34:   80 9f 00 08     lwz     r4,8(r31)
	  38:   7d 25 4b 78     mr      r5,r9
	  3c:   7d 46 53 78     mr      r6,r10
	  40:   48 00 00 01     bl      printf
	  44:   7c 60 1b 78     mr      r0,r3
	  48:   7c 03 03 78     mr      r3,r0
	  4c:   48 00 00 04     b       50 <float_print+0x50>
	  50:   81 61 00 00     lwz     r11,0(r1)
	  54:   80 0b 00 04     lwz     r0,4(r11)
	  58:   7c 08 03 a6     mtlr    r0
	  5c:   83 eb ff fc     lwz     r31,-4(r11)
	  60:   7d 61 5b 78     mr      r1,r11
	  64:   4e 80 00 20     blr

I've heard and have read in back messages that this problem lies in either
the varags implementation or in the stdio-common (i.e. printf) bits of
glibc. Does anyone have a patch which addresses this specific problem?

This problem happens on both a Solaris/SPARC to Linux/PPC cross compiler
as well as on a native Linux/PPC compiler. The former is
gcc-2.95.3-20010112 (prerelease) with glibc-2.1.3 and the latter is
gcc-2.95.2-19991024 (release/franzo) with 'glibc-2.1.3 from
'glibc-2.1.3-4a'.

For the cross-compiler, the compiler and libraries were configured w/

	GCC:

	./configure --host=sparc-sun-solaris2.7 --target=powerpc-linux
	--prefix=$TOOLROOT/host/sparc-sun-solaris
	--with-headers=$TOOLROOT/target/powerpc-linux-gnu/include
	--with-libs=$TOOLROOT/target/powerpc-linux-gnu/lib
	--enable-shared --enable-languages=c,c++
	--with-cpu=403 --without-fp

	GLIBC:

	./configure --host=powerpc-linux --with-headers=/usr/src/linux/include
	--enable-shared --enable-add-ons=crypt,linuxthreads
	--prefix=$TOOLROOT/target/powerpc-linux-gnu --without-fp

The test code:

main.c:

int main (void)
{
        float value;
        int status;

        value = pi();
        status = float_print("The value of Pi is approximately", value);

        return (status);
}

pi.c:

float
pi(void)
{
        return (22.0/7.0);
}

float_print.c:

int float_print(const char *string, float value)
{
        return (printf("%s: %f\n", string, value));
}


--
 Grant Erickson                       University of Minnesota Alumni
  o mail:erick205@umn.edu                                 1996 BSEE
  o http://www.umn.edu/~erick205                          1998 MSEE

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Patch for Soft-Float Problems w/ Glibc & Gcc?

[Ralph Blach]

[-- Attachment #1: Type: text/plain, Size: 4584 bytes --]

Grant,

As I understand it, Softfloat does NOT produce software emulation.
One must have a library to which to link inorder to floating point in
this situation.

The MontaVista toolset seems to have the floating point emulation in it.

Chip

Grant Erickson wrote:
>
> For some time I've noted but have never bothered chasing down the *printf
> problems associated with using -msoft-float/-D_SOFT_FLOAT on Linux/PPC.
>
> Needing to remedy the issue, I started chasing it down using the code
> samples below. When compiled using just '$(CROSS_COMPILE)gcc -o pi-test
> *.c' everything works fine:
>
>         user@host% ./pi-test
>         The value of Pi is approximately: 3.142857
>
> If I turn-around and compile it with '$(CROSS_COMPILE)gcc -o pi-test
> -msoft-float *.c' or '$(CROSS_COMPILE)gcc -o pi-test -msoft-float
> -D_SOFT_FLOAT *.c' I get:
>
>         user@host% ./pi-test
>         The value of Pi is approximately: 0.000000
>
> After disassembling the code, from what I can see both bits of code are
> generating the right output for the IEEE single-precision result. Both
> bits of code appear to be following the correct register callee/caller
> convetions for both 'pi' and 'float_print'. So, I have to assume that the
> problem lies somewhere within either the '__extendsfdf2' or 'printf'
> subroutine calls within 'float_print':
>
>         Disassembly of section .text:
>
>         00000000 <float_print>:
>            0:   94 21 ff e0     stwu    r1,-32(r1)
>            4:   7c 08 02 a6     mflr    r0
>            8:   93 e1 00 1c     stw     r31,28(r1)
>            c:   90 01 00 24     stw     r0,36(r1)
>           10:   7c 3f 0b 78     mr      r31,r1
>           14:   90 7f 00 08     stw     r3,8(r31)
>           18:   90 9f 00 0c     stw     r4,12(r31)
>           1c:   80 7f 00 0c     lwz     r3,12(r31)
>           20:   48 00 00 01     bl      __extendsfdf2
>           24:   7c 69 1b 78     mr      r9,r3
>           28:   7c 8a 23 78     mr      r10,r4
>           2c:   3d 60 00 00     lis     r11,.rodata@h
>           30:   38 6b 00 00     addi    r3,r11,.rodata@l
>           34:   80 9f 00 08     lwz     r4,8(r31)
>           38:   7d 25 4b 78     mr      r5,r9
>           3c:   7d 46 53 78     mr      r6,r10
>           40:   48 00 00 01     bl      printf
>           44:   7c 60 1b 78     mr      r0,r3
>           48:   7c 03 03 78     mr      r3,r0
>           4c:   48 00 00 04     b       50 <float_print+0x50>
>           50:   81 61 00 00     lwz     r11,0(r1)
>           54:   80 0b 00 04     lwz     r0,4(r11)
>           58:   7c 08 03 a6     mtlr    r0
>           5c:   83 eb ff fc     lwz     r31,-4(r11)
>           60:   7d 61 5b 78     mr      r1,r11
>           64:   4e 80 00 20     blr
>
> I've heard and have read in back messages that this problem lies in either
> the varags implementation or in the stdio-common (i.e. printf) bits of
> glibc. Does anyone have a patch which addresses this specific problem?
>
> This problem happens on both a Solaris/SPARC to Linux/PPC cross compiler
> as well as on a native Linux/PPC compiler. The former is
> gcc-2.95.3-20010112 (prerelease) with glibc-2.1.3 and the latter is
> gcc-2.95.2-19991024 (release/franzo) with 'glibc-2.1.3 from
> 'glibc-2.1.3-4a'.
>
> For the cross-compiler, the compiler and libraries were configured w/
>
>         GCC:
>
>         ./configure --host=sparc-sun-solaris2.7 --target=powerpc-linux
>         --prefix=$TOOLROOT/host/sparc-sun-solaris
>         --with-headers=$TOOLROOT/target/powerpc-linux-gnu/include
>         --with-libs=$TOOLROOT/target/powerpc-linux-gnu/lib
>         --enable-shared --enable-languages=c,c++
>         --with-cpu=403 --without-fp
>
>         GLIBC:
>
>         ./configure --host=powerpc-linux --with-headers=/usr/src/linux/include
>         --enable-shared --enable-add-ons=crypt,linuxthreads
>         --prefix=$TOOLROOT/target/powerpc-linux-gnu --without-fp
>
> The test code:
>
> main.c:
>
> int main (void)
> {
>         float value;
>         int status;
>
>         value = pi();
>         status = float_print("The value of Pi is approximately", value);
>
>         return (status);
> }
>
> pi.c:
>
> float
> pi(void)
> {
>         return (22.0/7.0);
> }
>
> float_print.c:
>
> int float_print(const char *string, float value)
> {
>         return (printf("%s: %f\n", string, value));
> }
>
> --
>  Grant Erickson                       University of Minnesota Alumni
>   o mail:erick205@umn.edu                                 1996 BSEE
>   o http://www.umn.edu/~erick205                          1998 MSEE
>

[-- Attachment #2: Card for Ralph Blach --]
[-- Type: text/x-vcard, Size: 247 bytes --]

begin:vcard
n:Blach;Ralph
tel;work:919-543-1207
x-mozilla-html:TRUE
url:www.ibm.com
org:IBM MicroElectronics
adr:;;3039 Cornwallis		;RTP;NC;27709;USA
version:2.1
email;internet:rcblach@raleigh.ibm.com
x-mozilla-cpt:;15936
fn:Ralph Blach
end:vcard

Re: Patch for Soft-Float Problems w/ Glibc & Gcc?

[Mark Hatle]

Grant Erickson wrote:
>
> For some time I've noted but have never bothered chasing down the *printf
> problems associated with using -msoft-float/-D_SOFT_FLOAT on Linux/PPC.
>
> Needing to remedy the issue, I started chasing it down using the code
> samples below. When compiled using just '$(CROSS_COMPILE)gcc -o pi-test
> *.c' everything works fine:
>
> ...

I believe we fixed this problem around CDK 1.2 time.  Unfortunatly I
don't remember what we did to fix the problem.  I am almost sure it has
to do with the spec file for gcc.  (not rpm spec, but the
...lib/gcc-lib/2.95.2/spec.

Give the CDK 1.2 compiler a try on that code and see if it fixes the
problem you are having.  (Keep in mind that you will also need to use
the glibc provided.  The floating point printf fix effects both glibc
and gcc.)

ftp://ftp.mvista.com/pub/CDK/1.2

If that does fix your problem I can help you track down the patch that
does the fix.  (It's been 6 or so months since I made these patches so
my memory is a bit fuzzy right now.)

--Mark

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Patch for Soft-Float Problems w/ Glibc & Gcc?

[Mark Hatle]

Ralph Blach wrote:
>
> Grant,
>
> As I understand it, Softfloat does NOT produce software emulation.
> One must have a library to which to link inorder to floating point in
> this situation.
>
> The MontaVista toolset seems to have the floating point emulation in it.

Actually thats only partially true.. the floating point "library" is
internal to gcc on PowerPC processors.. and on all of the processors
that MontaVista supports.

gcc/config/fp-bit.c is the file included with gcc to support
soft-floating point.

--Mark

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

RE: Patch for Soft-Float Problems w/ Glibc & Gcc?

[Timothy Pollock]

powerpc-eabi-objdump -S ces | egrep
'mtfsf|lfd|lfs|stfd|stflwx|stfs|:[ \t]*(fc|fd|fe|ff|ec|ed|ee|ef) '

Here's a useful little one-liner that lets you find out if there are any
floating point instructions in an object file.


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Patch for Soft-Float Problems w/ Glibc & Gcc?

[Grant Erickson]

On Tue, 13 Feb 2001, Mark Hatle wrote:
> Grant Erickson wrote:
> > For some time I've noted but have never bothered chasing down the *printf
> > problems associated with using -msoft-float/-D_SOFT_FLOAT on Linux/PPC.
> >
> > Needing to remedy the issue, I started chasing it down using the code
> > samples below. When compiled using just '$(CROSS_COMPILE)gcc -o pi-test
> > *.c' everything works fine:
> >
> > ...
>
> I believe we fixed this problem around CDK 1.2 time.  Unfortunatly I
> don't remember what we did to fix the problem.  I am almost sure it has
> to do with the spec file for gcc.  (not rpm spec, but the
> ...lib/gcc-lib/2.95.2/spec.
>
> Give the CDK 1.2 compiler a try on that code and see if it fixes the
> problem you are having.  (Keep in mind that you will also need to use
> the glibc provided.  The floating point printf fix effects both glibc
> and gcc.)

The one patch that makes the difference is the following:

diff -urN gcc-2.95.2.orig/gcc/config/rs6000/linux-nfp.h gcc-2.95.2/gcc/config/rs6000/linux-nfp.h
--- gcc-2.95.2.orig/gcc/config/rs6000/linux-nfp.h       Wed Dec 31 16:00:00 1969
+++ gcc-2.95.2/gcc/config/rs6000/linux-nfp.h    Tue May 30 18:34:05 2000
@@ -0,0 +1,34 @@
+/* Target definitions for GNU compiler for PowerPC running System V.4
+   Copyright (C) 1995, 1996, 1997, 1998, 1999 Free Software Foundation,
Inc.
+   Contributed by Cygnus Support.
+
+Default to soft floating point.
+
+This file is part of GNU CC.
+
+GNU CC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 2, or (at your option)
+any later version.
+
+GNU CC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License
+along with GNU CC; see the file COPYING.  If not, write to
+the Free Software Foundation, 59 Temple Place - Suite 330,
+Boston, MA 02111-1307, USA.  */
+
+#include "linux.h"
+
+#undef CPP_SYSV_SPEC
+#define CPP_SYSV_SPEC \
+"%{mrelocatable*: -D_RELOCATABLE} \
+%{fpic: -D__PIC__=1 -D__pic__=1} \
+%{!fpic: %{fPIC: -D__PIC__=2 -D__pic__=2}} \
+%{mcall-sysv: -D_CALL_SYSV} %{mcall-nt: -D_CALL_NT} \
+%{mcall-aix: -D_CALL_AIX} %{mcall-aixdesc: -D_CALL_AIX -D_CALL_AIXDESC} \
+%{!mcall-sysv: %{!mcall-aix: %{!mcall-aixdesc: %{!mcall-nt: %(cpp_sysv_default) }}}} \
+%{!mhard-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}"
diff -urN gcc-2.95.2.orig/gcc/configure gcc-2.95.2/gcc/configure
--- gcc-2.95.2.orig/gcc/configure       Wed Oct 13 00:58:02 1999
+++ gcc-2.95.2/gcc/configure    Tue May 30 18:27:12 2000
@@ -5127,7 +5127,12 @@
                fi
                ;;
        powerpc-*-linux-gnu*)
-               tm_file=rs6000/linux.h
+               if test x$with_fp = xno
+               then
+                       tm_file=rs6000/linux-nfp.h
+               else
+                       tm_file=rs6000/linux.h
+               fi
                xm_file="xm-siglist.h rs6000/xm-sysv4.h"
                xm_defines="USG ${xm_defines}"
                out_file=rs6000/rs6000.c

This is included with all of the other non-FPU patches typically applied
for the 4xx or 8xx processors. The one single difference that this has is
on the spec file produced for gcc. What was:

*cpp_sysv:
[ ... some stuff ... ] {msoft-float: -D_SOFT_FLOAT} [ ... more stuff ... ]

changes to:

*cpp_sysv:
[ ... some stuff ... ] {!mhard-float: -D_SOFT_FLOAT} [ ... more stuff ... ]

After regenerating gcc 2.95.3-test3 and glibc 2.1.3, the results are
promising:

	grant@stcroix% ./pi-test-hard
	The value of Pi is approximately: 3.142857

	grant@stcroix% ./pi-test-soft
	The value of Pi is approximately: 3.142857

Thanks a lot to those who offered suggestions over the course of the day!

Best regards,

Grant Erickson


--
 Grant Erickson                       University of Minnesota Alumni
  o mail:erick205@umn.edu                                 1996 BSEE
  o http://www.umn.edu/~erick205                          1998 MSEE


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/