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 [email protected]
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.
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
"[email protected], 2003-06-26 20:35:32-07:00, [email protected]")
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
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.
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.
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
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.
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