This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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 ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |