Problems with crossgcc and AMD Au1550

[Kai Ruottu]

Chris Jones wrote:

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

   ftp://ftp.kernel.org

  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.

  Ok, my own Linux-binutils aren't that new either:

/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

Neither the GCC version is that new:

/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=7804

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

  If wee look at the main config template for this target:

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') :

In archive libgcc.a:

_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]

  The 'mipsisa32el-linux-gnu' target then has :

In archive libgcc.a:

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

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