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] | |
TARGET=mipsel-unknown-linux-gnu
TARGET_CFLAGS="-O2 -finline-limit=10000"
GLIBC_EXTRA_CONFIG="--without-fp --with-cpu=mips32"
gcc-3.3.2-glibc-2.3.2.dat:
The current gcc-3.3 bugfix version is gcc-3.3.4, the gcc-3.3.2 became obsolete when the gcc-3.3.3 appeared, so please use the up-to-date FSF gcc-3.3 release !
BINUTILS_DIR=binutils-2.15
Please also use the Linux-binutils, the '2.15.91.0.1' should still be the up-to-date one !
Although the '2.15' would claim it being quite new, there is always a long delay from the freezing to the release and the 2.15 may be something from the late 2003 and not at all tested with Linux because Linux has it's own binutils releases, tested just with the Linuces... AFAIK
GCC_DIR=gcc-3.3.2
GLIBC_DIR=glibc-2.3.2
LINUX_DIR=linux-2.4.25
GLIBCTHREADS_FILENAME=glibc-linuxthreads-2.3.2
I get the same errors as in my earlier post.
It is fully possible that both gcc-3.3.2 and the binutils-2.15 have serious bugs with Linux/MIPSel, so trying the up-to-date versions is the first operation in these cases. Bugs are still under fixing with gcc-3.3, the gcc-3.3.4 definitely isn't the last member in the 'gcc-3.3' branch. The current gcc-3.3.5 prerelease is the gcc-3.3-20040609, so either this or the official FSF release, gcc-3.3.4, should be tried first...
When specifying the -mips32 in the Makefile, I get a different set of
errors: /tmp/ccnRj7Gb.s: Assembler messages:
/tmp/ccnRj7Gb.s:7492: Error: Cannot branch to symbol in another section.
/tmp/ccnRj7Gb.s:7553: Error: Cannot branch to symbol in another section.
/tmp/ccnRj7Gb.s:8025: Error: Cannot branch to symbol in another section.
As seen, the assembler gives these errors, so either it doesn't grok something (which is right) or cc1 produces something which is wrong... So your bug report should go either to the binutils or to the gcc-bug list but first you should use the up-to-date versions from both branches.
/home3/usr/local/mipsel-linux-gnu > bin/ld -V GNU ld version 2.14.90.0.7 20031029 Supported emulations: elf32ltsmip elf32btsmip elf32ltsmipn32 elf64ltsmip elf32btsmipn32 elf64btsmip
/home3/usr/local/lib/gcc-lib/mipsel-linux-gnu/3.3.2 > ./cc1 --version
GNU C version 3.3.2 (mipsel-linux-gnu)
compiled by GNU C version 3.2.3.
GGC heuristics: --param ggc-min-expand=34 --param ggc-min-heapsize=7804So maybe I too should do something with these... I though have produced these only just for a fun and getting them built has been enough. No kernel builds, 'mipsel-linux' hosted toolchain builds and such yet...
It sort of makes sense that I'm getting the "not supported on this processor"
because my mipsel-unknown-linux-gnu-gcc seems to not be using the mips32
by default (even though I specified this above).
Ok, you have that '-finline-limit=10000' for GCC, and the "--without-fp --with-cpu=mips32" in the glibc config, so wanting to produce tools for soft-float. But the '--without-fp' doesn't automagically trigger '-msoft-float' to be used with GCC when compiling glibc, so at least the '-msoft-float' should be added to the TARGET_CFLAGS. And you must use it when compiling the kernel, as the matter of fact, ALWAYS, unless you modify your GCC to default to '-msoft-float'...
mips*-*-linux*) # Linux MIPS, either endian.
tm_file="dbxelf.h elfos.h svr4.h linux.h ${tm_file} mips/linux.h"
case $machine in
mipsisa32*-*)
target_cpu_default="MASK_SOFT_FLOAT"
tm_defines="MIPS_ISA_DEFAULT=32"
;;
esac
tmake_file="t-slibgcc-elf-ver t-linux mips/t-linux"
;;it shows that the 'mipsisa32el-linux-gnu' target name would put the '-msoft-float' being the default... But what is the difference between the 'mips*' and 'mipsisa32*', besides these, has stayed a little fuzzy...
The "ll" and "sc" instructions are in the mips2 ISA, NOT in mips1. But my question is this: Why is the compiler generating bad code?
It is possible but when compiling libgcc, libiberty and libstdc++ coming with gcc-3.3.2, this didn't happen with my toolchain... If checking the produced objects in the libs, they are all for mips1, like (using 'mipsel-linux-gnu-objdump -p') :
_muldi3.oS: file format elf32-tradlittlemips private flags = 1007: [abi=O32] [mips1] [not 32bitmode]
_negdi2.oS: file format elf32-tradlittlemips private flags = 1007: [abi=O32] [mips1] [not 32bitmode]
_lshrdi3.oS: file format elf32-tradlittlemips private flags = 1007: [abi=O32] [mips1] [not 32bitmode]
_muldi3.oS: file format elf32-tradlittlemips private flags = 50001007: [abi=O32] [mips32] [not 32bitmode]
_negdi2.oS: file format elf32-tradlittlemips private flags = 50001007: [abi=O32] [mips32] [not 32bitmode]
_lshrdi3.oS: file format elf32-tradlittlemips private flags = 50001007: [abi=O32] [mips32] [not 32bitmode]
but I should do my homework and learn the differences between all these MIPS ISA variations...
Smelling more like a gcc problem.
Could you post the offending 'zaptel.c', a search in my plain vanilla kernel sources (2.4.22 and 2.5.63) didn't show this file being there... Trying to compile it with our toolchains could tell if we all here have just the same problem and should try those more up-to-date FSF-gcc/Linux binutils versions.
------ 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] |