Re: Cross GCC3 for PPC (no fpu)

[Dan Kegel <dank at kegel dot com>]

Kai Ruottu wrote:
> 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...

The script is to be used in an automated build system.  Our policy is
that *everything* is built from virgin sources.  Hence the need for
a complete, working way of building a toolchain.
 
>  With the 'powerpc-linux-gnu' target nobody needs to start from scratch because
> there are prebuilt Linux/PPC-distributions available.

We don't want to use tricks like that - it should be easy to build from
virgin sources, and if it's not, there's something amiss in the virgin
sources.  It's nice to push the issue sometimes and show very clearly
(e.g. by demonstration) that the build process for gcc/glibc has problems,
so they can be fixed, so future developers don't need to use handy but
shady tricks like borrowing headers from an existing system.

>  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 ?

The ppc403/405 fp emulator in the kernel is broken and is not used by anyone 
(particularly us), so we probably need the soft-float routines in libgcc.a.

> > I was passing --without-fp to glibc's configure, and "-mcpu=403" was in
> > CFLAGS, but it seems __setfpucw was still being built into glibc.
>
>  If it should 'initialize the math-emu', then it should be there even in
> the 'soft-float'-case...

IMHO Dimi should look at the implementation of __setfpucw in libgcc.a,
and see if there are two implementations: one for soft-float, and one
for hard-float.  Perhaps the wrong one is switched on.

>  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. 

Thanks for the tip!

- Dan
(who works with Dimi)

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com