2.5.73 on alpha/smp build failure

2.5.73 on alpha/smp build failure

[T. Weyergraf]

Hi all,

I  tried to build 2.5.73 on my SMP alpha, but get the following
compile-time failure:

[...]
  CHK     include/linux/compile.h
  UPD     include/linux/compile.h
  CC      init/version.o
  LD      init/built-in.o
  LD      vmlinux
ld: arch/alpha/kernel/built-in.o: !samegp reloc against symbol without .prologue: memset
make[1]: *** [vmlinux] Error 1
make: *** [vmlinux] Error 1

I tried gcc-3.3 and 2.95.4, binutils is 2.14.90.0.4

This problem has been introduced with the __kernel_execve 
reimplementation. 

Any ideas ?  ( what puzzles me, is that i am apparently the only
alpha user with that problem... )

Regards,
Thomas Weyergraf



-- 
Thomas Weyergraf                                                kirk@colinet.de
My Favorite IA64 Opcode-guess ( see arch/ia64/lib/memset.S )
"br.ret.spnt.few" - got back from getting beer, did not spend a lot.

Re: 2.5.73 on alpha/smp build failure

[Oleg Drokin]

Hello!

On Sat, Jun 28, 2003 at 11:28:13AM +0200, T. Weyergraf wrote:

> Any ideas ?  ( what puzzles me, is that i am apparently the only
> alpha user with that problem... )

Speaking of alphas, I have strange alpha problem myself.
When I compile the kernel the alpha itself (tried shipped suse 8.1 gcc 3.2.2
and self-compiled gcc 2.95.3), it jumps to the address zero quickly after
launching init and panics.
If I cross compile kernel with crosscompiler (2.95.3) on my x86 PC,
kernel boots, but there are a lot of strangeness happens.
For example find a program below, if I compile it with a cross-compiler,
it produces "vs-500: unknown uniqueness -2" message, but if compiled with
a native compiler it produces expected "result is 1".
This code below is a part of reiserfs code, and when it does not work
as expected, no wonder reiserfs breaks in a lot of funny ways.
(besides the fact that I was debugging other reiserfs problem on 64 bit platforms).
Also in kernel compiled with the crosscompiler, pty/tty stuff does not work and
other funny errors from other parts of kernel (but still this is much better compared
to native compile). Of course the config is the same for both native and crosscompilation.
Kernel I am compiling is 2.5.73+ (some bk snapshot, last changeset is this
"ChangeSet@1.1505, 2003-06-26 20:35:32-07:00, greg@kroah.com")

I wonder is anyone have any advices on how to overcome those problems I am facing.
Our Alpha is a Ruffian-type of system with EV56 500 Mhz CPU.

The testcase code is (if you cast uniqueness to int in the switch(), it works as expected
even with crosscompiler):

#include <stdio.h>
#include <sys/types.h>
#define V1_DIRECT_UNIQUENESS 0xffffffff
#define V1_DIRENTRY_UNIQUENESS 500
#define V1_ANY_UNIQUENESS 555 // FIXME: comment is required
#define V1_INDIRECT_UNIQUENESS 0xfffffffe
#define V1_SD_UNIQUENESS 0

#define TYPE_STAT_DATA 0
#define TYPE_INDIRECT 1
#define TYPE_DIRECT 2
#define TYPE_DIRENTRY 3
#define TYPE_MAXTYPE 3
#define TYPE_ANY 15 // FIXME: comment is required

static inline int uniqueness2type (unsigned int uniqueness)
{
    switch (uniqueness) {
    case V1_SD_UNIQUENESS: return TYPE_STAT_DATA;
    case V1_INDIRECT_UNIQUENESS: return TYPE_INDIRECT;
    case V1_DIRECT_UNIQUENESS: return TYPE_DIRECT;
    case V1_DIRENTRY_UNIQUENESS: return TYPE_DIRENTRY;
    default:
printf("vs-500: unknown uniqueness %d\n", uniqueness);
return TYPE_ANY;
    }
}

int main(void)
{
unsigned int a=V1_INDIRECT_UNIQUENESS;
printf("result is %d\n", uniqueness2type(a));
return 0;
}

Bye,
    Oleg

Re: 2.5.73 on alpha/smp build failure

[Ivan Kokshaysky]

On Sat, Jun 28, 2003 at 11:28:13AM +0200, T. Weyergraf wrote:
> ld: arch/alpha/kernel/built-in.o: !samegp reloc against symbol without .prologue: memset
> make[1]: *** [vmlinux] Error 1
...
> Any ideas ?  ( what puzzles me, is that i am apparently the only
> alpha user with that problem... )

No, I've seen this too. Fixed in current BK.

Ivan.

Re: 2.5.73 on alpha/smp build failure

[Ivan Kokshaysky]

On Sat, Jun 28, 2003 at 05:38:18PM +0400, Oleg Drokin wrote:
> When I compile the kernel the alpha itself (tried shipped suse 8.1 gcc 3.2.2
> and self-compiled gcc 2.95.3), it jumps to the address zero quickly after
> launching init and panics.

Most likely it's binutils problem. Versions 2.13.90.0.18 and newer
should be OK, as discussed recently on l-k.

Ivan.

Re: 2.5.73 on alpha/smp build failure

[Oleg Drokin]

[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]

Hello!

On Sun, Jun 29, 2003 at 03:56:16PM +0400, Ivan Kokshaysky wrote:

> > When I compile the kernel the alpha itself (tried shipped suse 8.1 gcc 3.2.2
> > and self-compiled gcc 2.95.3), it jumps to the address zero quickly after
> > launching init and panics.
> Most likely it's binutils problem. Versions 2.13.90.0.18 and newer
> should be OK, as discussed recently on l-k.

I have :
$ alphaev56-unknown-linux-gnu-size -V
GNU size 2.14 20030612
Copyright 2002 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.

Also I tried to compare assembly output of native vs crosscompiler and have found the result to be
different substantionally (unfortunatelly I cannot understand alpha assembly, but I see the
code looks different in the beginning. Also assembly file generated by cross-gcc produces
wrong result after translated/linked using native binutils). I assume that binutils are not involved in
"gcc -S" process.

See attached assembly generated by cross compiler vs native compiler.

Bye,
    Oleg

[-- Attachment #2: test-cross.s --]
[-- Type: text/plain, Size: 581 bytes --]

	.file	1 "test.c"
	.set noat
	.set noreorder
	.arch ev56
.section	.rodata
$LC0:
	.ascii "vs-500: unknown uniqueness %d\12\0"
$LC1:
	.ascii "result is %d\12\0"
.text
	.align 5
	.globl main
	.ent main
main:
	.frame $30,0,$26,0
	.mask 0x4000000,0
	ldgp $29,0($27)
$main..ng:
	lda $30,-16($30)
	lda $16,$LC0
	lda $17,-2
	stq $26,0($30)
	.prologue 1
	zapnot $17,15,$17
	jsr $26,printf
	ldgp $29,0($26)
	nop
	lda $16,$LC1
	lda $17,15
	jsr $26,printf
	ldgp $29,0($26)
	ldq $26,0($30)
	mov $31,$0
	lda $30,16($30)
	ret $31,($26),1
	.end main
	.ident	"GCC: (GNU) 2.95.3 20010315 (release)"

[-- Attachment #3: test-native.s --]
[-- Type: text/plain, Size: 500 bytes --]

	.file	1 "test.c"
	.set noat
	.set noreorder
	.arch ev56
.section	.rodata
$LC0:
	.ascii "vs-500: unknown uniqueness %d\12\0"
$LC1:
	.ascii "result is %d\12\0"
.text
	.align 5
	.globl main
	.ent main
main:
	.frame $30,16,$26,0
	.mask 0x4000000,-16
	ldgp $29,0($27)
$main..ng:
	lda $30,-16($30)
	lda $16,$LC1
	stq $26,0($30)
	.prologue 1
	lda $17,1
	jsr $26,printf
	ldgp $29,0($26)
	ldq $26,0($30)
	mov $31,$0
	lda $30,16($30)
	ret $31,($26),1
	.end main
	.ident	"GCC: (GNU) 2.95.3 20010315 (release)"

Re: 2.5.73 on alpha/smp build failure

[Ivan Kokshaysky]

On Mon, Jun 30, 2003 at 09:42:59AM +0400, Oleg Drokin wrote:
> I have :
> $ alphaev56-unknown-linux-gnu-size -V
> GNU size 2.14 20030612

Well, I guess it's cross binutils? What about native binutils
installed on alpha? The package shipped with suse 8.1
(binutils-2.12.90.0.15-27) doesn't work for 2.5 kernels.

> See attached assembly generated by cross compiler vs native compiler.

Code generated by gcc-2.95 is obviously bogus. Which is not surprising -
2.95 is known to be broken for 32-bit host -> 64-bit target
cross-compilation. Try something more recent. ;-)

Ivan.

Re: 2.5.73 on alpha/smp build failure

[Oleg Drokin]

Hello!

On Mon, Jun 30, 2003 at 02:52:43PM +0400, Ivan Kokshaysky wrote:

> > See attached assembly generated by cross compiler vs native compiler.
> Code generated by gcc-2.95 is obviously bogus. Which is not surprising -
> 2.95 is known to be broken for 32-bit host -> 64-bit target
> cross-compilation. Try something more recent. ;-)

Sigh. So I suddenly succeed in building cross gcc-3.3 that works correctly with
my simple test (for some reason it needed to disable dynamic libgcc build
before I was able to get at least something working). And now guess what?
I get "bad kernel unaligned access ..." message at the point where sda's partition
table would get normally printed. The first address printed is somewhere near end of
__make_request, the second address is prior to the kernel start, and two last numbers are
"22 31".
If I disable SCSI completely, it even boots and works which is of course a great
progress over what I had with gcc-2.95 (it boots off IDE anyway). ;)

I will try to get newer binutils on the box itself to see if it will make any
difference for the kernel built natively.

Bye,
    Oleg