Cross GCC3 for PPC (no fpu)

Kai Ruottu
Thu Jun 6 06:01:00 GMT 2002

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:

 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

         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


00000000 T __setfpucw		<---------- !!
00000000 t gcc2_compiled.

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 ''
didn't respond (has it been removed now?), so the questions were left somehow

Cheers, Kai

Want more information?  See the CrossGCC FAQ,
Want to unsubscribe? Send a note to

More information about the crossgcc mailing list