Re: Cross GCC3 for PPC (no fpu)

[Kai Ruottu]

Dimi Shahbaz wrote:
> 
> A recap: I'm trying to write a clean script that build a complete crossgcc
> toolchain (binutils, gcc3.0.4, and glibc2.2.5) from scratch.  See:
> 
>       http://www.dimator.org/~dimator/work/crossgcc/

 Basically I'm against these 'push the button and be happy'-scripts and prefer
people knowing what they are doing. The script-writer knows, but the users stay
just as dummy as earlier...

 With the 'powerpc-linux-gnu' target nobody needs to start from scratch because
there are prebuilt Linux/PPC-distributions available. Their glibc's may be only
for '-mhard-float' (or what the option is with PPC...), but one can build the
important 'bootstrap-GCC' using these 'bootstrap-glibc's during the build. 
Trying
to avoid installing a prebuilt glibc simply makes things very hard for novices.

 How to get a 'powerpc-linux-gnu' targeted GCC which produces code for some PPC-
model without the FPU as default and how to produce a glibc which uses 
soft-float
everywhere are two problems... I haven't thought these, not even know whether 
they
are real problems at all, but you seem to have thought them, so some basic 
'stupid
questions' :

 Meanwhile the embedded 'ppc-eabi' uses the soft-float routines in 'libgcc.a',
using the 'fp-bit.c/dp-bit.c' etc. there, how does Linux/PPC handle these 
things ?
Does the Linux-kernel have a 'FPU-emulator' a'la Linux/x86, or are the same 
soft-
float routines in 'libgcc.a' used there too ?

 Quickly seen there is the 'linux/arch/ppc/math-emu' in the 'linux-2.4.18' 
sources,
so it seems that the routines in 'libgcc.a' will be replaced with something 
else...

> With help from Bill's FAQ and this list, I've gotten the PPC405
> toolchain to build.  Executables generated by the toolchain failed to
> run, however.  They returned an "Illegal Instruction" error message,
> which gdb reported was due to a '__setfpucw' instruction being called.
> This symbol was in libc.a.

 Shouldn't this 'initialize the math-emu' in the soft-float case ? Or should 
there
even be a 'soft-float' case ?  Should only the 'hard-float'-case exist and the
kernel using some 'traps', 'exception-handling' etc. when a FPU-instruction 
happens?
Ie. the 'math-emu' handles there 'traps' or 'exceptions' ?  For which purpose 
the
math-emu is there in the kernel if the basic 'fadd/fsub/fdiv/fmul' etc. is in 
the
'libgcc.a' ?

 For me the '__setfpucw' looks like being a called function, not a 
CPU-instruction :

H:\usr\local\ppc-linux-gnu\lib>..\bin\nm libc.a | less

init-first.o:
         U __environ
         U __fpu_control
         U __getopt_clean_environment
00000004 C __libc_argc
00000004 C __libc_argv
         U __libc_init
00000088 T __libc_init_first
         U __libc_init_secure
00000000 G __libc_multiple_libcs
         U __personality
         U __setfpucw           <---------- !!
000000a8 T _dl_start
         w _dl_starting_up
         U abort
00000000 t gcc2_compiled.
00000000 t init

...skipping...

setfpucw.o:
00000000 T __setfpucw           <---------- !!
00000000 t gcc2_compiled.

fpu_control.o:
00000000 G __fpu_control
00000000 t gcc2_compiled.

> I was passing --without-fp to glibc's configure, and "-mcpu=403" was in
> CFLAGS, but it seems this symbol was still being built into glibc.

 If it should 'initialize the math-emu', then it should be there even in
the 'soft-float'-case...

> Has anyone else ran into this?  Is there a better way to disable the FPU
> objects/calls from the build?

 As you have seen from my 'stupid questions', even the basic issues about
the 'without-FPU' approach in Linux/PPC are still unclear to me... Lets
hope they are clear to you, but anyhow I feeled right to ask these now...

 The x86-PCs and how those 386DXs and 486SXs without the '387/487' handle
the FPU-instructions are well-known and the Linux/x86 developers don't
need to care about these things -- the kernel and the 'x87'-emu there
take care of the 'exceptions'... But how the 'standard-PPC-hardware' (what
is this ?) handles the 'FPU-exceptions' (or are there any?), is unknown.
Just as are the things in Linux/MIPS, Linux/ARM etc...

 Recently I tried the 'xscale-linux-gnu' target ('soft-float' only) and met
something equal with the plain vanilla glibc-2.2.5 sources but the patched
glibc-2.2.5 sources for 'x86_64' seemed to fix the build. The 'www.armlinux.org'
didn't respond (has it been removed now?), so the questions were left somehow
open...

Cheers, Kai