linux-mips-fnet
[Top] [All Lists]

Re: GCC crosscompiler problem on Alpha

To: linux-mips@fnet.fr
Subject: Re: GCC crosscompiler problem on Alpha
From: Thomas Bogendoerfer <tsbogend@bigbug.franken.de>
Date: Wed, 8 May 1996 18:33:24 +0200 (MET DST)
In-reply-to: <199605072346.BAA01934@bigbug.franken.de> from "Thomas Bogendoerfer" at May 8, 96 01:46:26 am
Reply-to: tsbogend@bigbug.franken.de
> Today I have done a quick hack, and compiled the cross compiler
> with #define HOST_WIDE_INT int (which is 32bit wide). Now the
> code looks much better, but there are still minor differences.

Update: I found the reason for the minor differences. I only
rebuilt cc1 and not cpp. So the test for (~0UL) == 0xffffffff
in asm-mips/types.h fails and I ended up with a u64 which was
only 32bit wide:-(

Next thing which hit me, is a bug in gas. On a 64bit machine it
translates dli 0x100000000 to nothing. I first wondered why nobody
else had this problem before, but I realized that on a 32bit
platform bignums are used for numbers wider than 32bit.

Finally there are some problems in the .S files with loading
of pointers. Example:

arch/mips/lib/csum.S:

#include <asm/asm.h>
#include <asm/regdef.h>
#include <asm/segment.h>

/*
 * Compute kernel code checksum to check kernel code against corruption
 */
                LEAF(csum)
                jal     sys_cacheflush
                move    t8,ra                   # delay slot
                li      t0,KSEG1
                la      t1,final
                li      t2,KSEG1

on my 386 this will result in:

00000000 <csum> jal 00000000 <csum>
...
00000008 <csum+8> move $t8,$ra
0000000c <csum+c> lui $t0,40960
00000010 <csum+10> lui $t1,0
00000014 <csum+14> daddiu $t1,$t1,0
00000018 <csum+18> lui $t2,40960

as you can see t0 is not loaded with 0xa0000000 but with 0xffffffffa0000000.
The alpha mipsel-linux-as generates following code:

0000000000000000 <csum> jal 0000000000000000 <csum>
...
0000000000000008 <csum+8> move $t8,$ra
000000000000000c <csum+c> li $t0,40960
0000000000000010 <csum+10> dsll $t0,$t0,0x10
0000000000000014 <csum+14> lui $t1,0
0000000000000018 <csum+18> daddiu $t1,$t1,0
000000000000001c <csum+1c> li $t2,40960
0000000000000020 <csum+20> dsll $t2,$t2,0x10

To get the wanted result I had to modify csum.S a little bit:

#include <asm/asm.h>
#include <asm/regdef.h>
#include <asm/segment.h>

/*
 * Compute kernel code checksum to check kernel code against corruption
 */
                LEAF(csum)
                jal     sys_cacheflush
                move    t8,ra                   # delay slot
                li      t0,(KSEG1 | 0xffffffff00000000)
                la      t1,final
                li      t2,(KSEG1 | 0xffffffff00000000)   


There are serveral places in arch/mips where the same problem occurs.

For me it looks like a assembler bug and a problem with some kernel
pointer in Linux/Mips.

But now the good news:

Console: colour MIPS-G364 128x48, 1 virtual console (max 63)
Calibrating delay loop.. ok - 49.87 BogoMIPS
VDMA: R4030 DMA pagetables initialized.
Memory: 31384k/32764k available (608k kernel code, 772k data)
Swansea University Computer Society NET3.034 for Linux 1.3.77
NET3: Unix domain sockets 0.12 for Linux NET3.033.
Swansea University Computer Society TCP/IP for NET3.034
IP Protocols: ICMP, UDP, TCP
Checking for 'wait' instruction...  unavailable.
Linux version 1.3.91 (root@alpha.franken.de) (gcc version 2.7.2) #38 Wed May 8 
18:06:09 MET DST 1996
Floppy drive(s): fd0 is 1.44M
Started kswapd v 1.4.2.2 
FDC 0 is a post-1991 82077
ne.c:v1.10 9/23/94 Donald Becker (becker@cesdis.gsfc.nasa.gov)
NE*000 ethercard probe at 0x300: 00 80 28 80 2b 70
eth0: NE2000 found at 0x300, using IRQ 10.
Sending BOOTP requests..... OK
Root-NFS: Got BOOTP answer from 193.175.24.66, my address is 193.175.24.69
Root-NFS: Got file handle for /tftpboot/193.175.24.69 via RPC
VFS: Mounted root (nfs filesystem).


Thomas.

-- 
That process _deserves_ to die ("My name is Linus Torvalds, prepare to 
die").                                [Linus Torvalds on linux-kernel]

<Prev in Thread] Current Thread [Next in Thread>