From: Ralph Blach <rcblach@raleigh.ibm.com>
To: Grant Erickson <erick205@umn.edu>
Cc: linuxppc-embedded@lists.linuxppc.org
Subject: Re: Patch for Soft-Float Problems w/ Glibc & Gcc?
Date: Tue, 13 Feb 2001 12:48:06 -0500 [thread overview]
Message-ID: <3A897356.3DAB1D3@raleigh.ibm.com> (raw)
In-Reply-To: Pine.SOL.4.20.0102131051470.8375-100000@garnet.tc.umn.edu
[-- 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
next prev parent reply other threads:[~2001-02-13 17:48 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-02-13 17:20 Patch for Soft-Float Problems w/ Glibc & Gcc? Grant Erickson
2001-02-13 17:48 ` Ralph Blach [this message]
2001-02-13 18:42 ` Mark Hatle
2001-02-13 17:54 ` Mark Hatle
2001-02-14 0:09 ` Timothy Pollock
2001-02-14 0:29 ` Grant Erickson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A897356.3DAB1D3@raleigh.ibm.com \
--to=rcblach@raleigh.ibm.com \
--cc=erick205@umn.edu \
--cc=linuxppc-embedded@lists.linuxppc.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).