I'm trying to build an x66-64 kernel on a 32 bit system (Ubuntu 5.10).
I added -m64 to the CFLAGS as per the gcc docs. But the build fails
with:
$ make ARCH=x86_64
[...]
CC init/initramfs.o
CC init/calibrate.o
LD init/built-in.o
CHK usr/initramfs_list
CC arch/x86_64/kernel/process.o
CC arch/x86_64/kernel/signal.o
AS arch/x86_64/kernel/entry.o
arch/x86_64/kernel/entry.S: Assembler messages:
arch/x86_64/kernel/entry.S:204: Error: cannot represent relocation type BFD_RELOC_X86_64_32S
arch/x86_64/kernel/entry.S:275: Error: cannot represent relocation type BFD_RELOC_X86_64_32S
arch/x86_64/kernel/entry.S:762: Error: cannot represent relocation type BFD_RELOC_X86_64_32S
arch/x86_64/kernel/entry.S:815: Error: cannot represent relocation type BFD_RELOC_X86_64_32S
arch/x86_64/kernel/entry.S:536: Error: cannot represent relocation type BFD_RELOC_64
arch/x86_64/kernel/entry.S:536: Error: cannot represent relocation type BFD_RELOC_64
arch/x86_64/kernel/entry.S:785: Error: cannot represent relocation type BFD_RELOC_64
arch/x86_64/kernel/entry.S:785: Error: cannot represent relocation type BFD_RELOC_64
make[1]: *** [arch/x86_64/kernel/entry.o] Error 1
make: *** [arch/x86_64/kernel] Error 2
Is this a known toolchain bug?
$ as --version
GNU assembler 2.16.1 Debian GNU/Linux
Lee
On Fri, 9 Dec 2005, Lee Revell wrote:
> I'm trying to build an x66-64 kernel on a 32 bit system (Ubuntu 5.10).
> I added -m64 to the CFLAGS as per the gcc docs. But the build fails
> with:
>
> $ make ARCH=x86_64
> [...]
> CC init/initramfs.o
> CC init/calibrate.o
> LD init/built-in.o
> CHK usr/initramfs_list
> CC arch/x86_64/kernel/process.o
> CC arch/x86_64/kernel/signal.o
> AS arch/x86_64/kernel/entry.o
> arch/x86_64/kernel/entry.S: Assembler messages:
> arch/x86_64/kernel/entry.S:204: Error: cannot represent relocation type BFD_RELOC_X86_64_32S
Unless ubuntu provides a biarch toolchain (and the fact gcc accepts
'-m64' means nothing - use 'file' on init/built-in.o), you have to build
a cross toolchain, (just binutils and gcc), put that on your path, and
use
make ARCH=x86_64 CROSS_COMPILE=x86_64-pc-linux-gnu-
so that the build will use x86_64-pc-linux-gnu-as and friends. You
should not need to mess with the CFLAGS.
Ken
--
das eine Mal als Trag?die, das andere Mal als Farce
On Fri, 2005-12-09 at 19:50 +0000, Ken Moffat wrote:
> On Fri, 9 Dec 2005, Lee Revell wrote:
>
> > I'm trying to build an x66-64 kernel on a 32 bit system (Ubuntu 5.10).
> > I added -m64 to the CFLAGS as per the gcc docs. But the build fails
> > with:
> >
> > $ make ARCH=x86_64
> > [...]
> > CC init/initramfs.o
> > CC init/calibrate.o
> > LD init/built-in.o
> > CHK usr/initramfs_list
> > CC arch/x86_64/kernel/process.o
> > CC arch/x86_64/kernel/signal.o
> > AS arch/x86_64/kernel/entry.o
> > arch/x86_64/kernel/entry.S: Assembler messages:
> > arch/x86_64/kernel/entry.S:204: Error: cannot represent relocation type BFD_RELOC_X86_64_32S
>
> Unless ubuntu provides a biarch toolchain (and the fact gcc accepts
> '-m64' means nothing - use 'file' on init/built-in.o), you have to build
> a cross toolchain, (just binutils and gcc), put that on your path, and
> use
>
> make ARCH=x86_64 CROSS_COMPILE=x86_64-pc-linux-gnu-
>
> so that the build will use x86_64-pc-linux-gnu-as and friends. You
> should not need to mess with the CFLAGS.
>
$ file init/built-in.o
init/built-in.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1
(SYSV), not stripped
>From man gcc, i386 section:
-m32
-m64
Generate code for a 32-bit or 64-bit environment. The 32-bit
environment sets int, long and pointer to 32
bits and generates code that runs on any i386 system. The
64-bit environment sets int to 32 bits and long
and pointer to 64 bits and generates code for AMD's x86-64
architecture.
Lee
On Fri, Dec 09, 2005 at 01:50:08PM -0500, Lee Revell wrote:
> I'm trying to build an x66-64 kernel on a 32 bit system (Ubuntu 5.10).
> I added -m64 to the CFLAGS as per the gcc docs. But the build fails
> with:
>
> $ make ARCH=x86_64
> arch/x86_64/kernel/entry.S:785: Error: cannot represent relocation type BFD_RELOC_64
Ubuntu/Debian provide a biarch gcc, but do not (did not?) provide a biarch
assembler. Building binutils for target x86_64-pc-linux-gnu should help.
On Fri, 2005-12-09 at 14:58 -0500, Kyle McMartin wrote:
> On Fri, Dec 09, 2005 at 01:50:08PM -0500, Lee Revell wrote:
> > I'm trying to build an x66-64 kernel on a 32 bit system (Ubuntu 5.10).
> > I added -m64 to the CFLAGS as per the gcc docs. But the build fails
> > with:
> >
> > $ make ARCH=x86_64
> > arch/x86_64/kernel/entry.S:785: Error: cannot represent relocation type BFD_RELOC_64
>
> Ubuntu/Debian provide a biarch gcc, but do not (did not?) provide a biarch
> assembler. Building binutils for target x86_64-pc-linux-gnu should help.
>
I thought that might be the problem so I installed an x86-64 binutils
from:
http://debian.speedblue.org
I tried with CROSS_COMPILE="/usr/x86_64/bin/x86_64-linux-", but edited
the Makefile to set CC to /use/bin/gcc. Same error.
Lee
On Fri, Dec 09, 2005 at 03:21:16PM -0500, Lee Revell wrote:
> I tried with CROSS_COMPILE="/usr/x86_64/bin/x86_64-linux-", but edited
> the Makefile to set CC to /use/bin/gcc. Same error.
>
Ah. I didn't realize when it says "AS foo.o" it really means it's running
CC, not AS. (I had also built a cross compiling gcc, but didn't realize it
was being used).
On Fri, 2005-12-09 at 15:41 -0500, Kyle McMartin wrote:
> On Fri, Dec 09, 2005 at 03:21:16PM -0500, Lee Revell wrote:
> > I tried with CROSS_COMPILE="/usr/x86_64/bin/x86_64-linux-", but edited
> > the Makefile to set CC to /use/bin/gcc. Same error.
> >
>
> Ah. I didn't realize when it says "AS foo.o" it really means it's running
> CC, not AS. (I had also built a cross compiling gcc, but didn't realize it
> was being used).
>
Yes, I noticed that, when I set KBUILD_VERBOSE, I can see that it just
invokes CC and passes -D__ASSEMBLY__.
So what is setting AS in the Makefile good for then? And how can I
force the build process to use /usr/x86_64/bin/x86_64-linux-as rather
than /usr/bin/as?
Also, isn't it a bug for the Makefile not to pass -m64 if I specify
ARCH=x86_64? If I don't change the CFLAGS I get:
$ make ARCH=x86_64
CHK include/linux/version.h
CC arch/x86_64/kernel/asm-offsets.s
arch/x86_64/kernel/asm-offsets.c:1: error: code model 'kernel' not
supported in the 32 bit mode
make[1]: *** [arch/x86_64/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2
Lee
On Fri, 2005-12-09 at 15:41 -0500, Kyle McMartin wrote:
> On Fri, Dec 09, 2005 at 03:21:16PM -0500, Lee Revell wrote:
> > I tried with CROSS_COMPILE="/usr/x86_64/bin/x86_64-linux-", but edited
> > the Makefile to set CC to /use/bin/gcc. Same error.
> >
>
> Ah. I didn't realize when it says "AS foo.o" it really means it's running
> CC, not AS. (I had also built a cross compiling gcc, but didn't realize it
> was being used).
The problem does not seem to be lack of x86-64 support in the assembler.
I symlinked /usr/bin/as to /usr/x86_64/bin/x86_64-linux-as and got the
exact same relocation error.
Lee
> The problem does not seem to be lack of x86-64 support in the assembler.
> I symlinked /usr/bin/as to /usr/x86_64/bin/x86_64-linux-as and got the
> exact same relocation error.
>
The problem appears to be that your GCC doesn't have support for these
relocations, not AS.
On Fri, 2005-12-09 at 15:58 -0500, Lee Revell wrote:
> Also, isn't it a bug for the Makefile not to pass -m64 if I specify
> ARCH=x86_64? If I don't change the CFLAGS I get:
>
> $ make ARCH=x86_64
> CHK include/linux/version.h
> CC arch/x86_64/kernel/asm-offsets.s
> arch/x86_64/kernel/asm-offsets.c:1: error: code model 'kernel' not
> supported in the 32 bit mode
> make[1]: *** [arch/x86_64/kernel/asm-offsets.s] Error 1
> make: *** [prepare0] Error 2
Lee,
For my x86_64, I gave up on trying to do it through the normal path
(having a plain debian unstable system), and finally just downloaded the
gcc toolchain (gcc, binutils, and glibc) and built them as cross
compilers with the prefix x86_64-linux-
For binutils I made a directory binutils_x86_64 and in there I used:
../binutils-2.16/configure --prefix=/usr/local/x86_64 --target=x86_64-linux
For gcc (first pass) I used:
../gcc-4.0.2/configure --prefix=/usr/local/x86_64 --target=x86_64-linux \
--enable-shared --disable-threads --enable-languages=c
That's enough to get a gcc that builds the kernel.
Then I built glibc, and then once again the gcc with:
../gcc-4.0.2/configure --prefix=/usr/local/x86_64 --target=x86_64-linux \
--enable-shared --with-headers=/usr/local/x86_64/include \
--with-libs=/usr/local/x86_64/lib --disable-multilib \
--enable-languages=c
Probably not the best way, but it worked for me ;-)
Now I also installed a hack make program in /usr/local/bin that is used first:
---
#!/bin/sh
if [ ! -z $__MY_MAKE_RUNNING__ ]; then
/usr/bin/make $*
exit $?
fi
__MY_MAKE_RUNNING__=1
export __MY_MAKE_RUNNING__
pwd=`pwd | sed -ne '/\/home\/rostedt\/work\/kernels\//p'`
if [ -z $pwd ]; then
m="intmake"
else
m="amdmake"
fi
# prove to me that I'm running the right one
echo $m
$m $*
---
with amdmake in /usr/local/bin:
---
PATH=$PATH:/usr/local/x86_64/bin/ make CROSS_COMPILE=x86_64-linux- ARCH=x86_64 $*
---
and intmake also in /usr/local/bin:
---
make ARCH=i386 $*
---
So now all the kernels in my /home/rostedt/work/kernels are built with
the cross compiling x86_64 and all other kernels for intel i386. I know
this is a major hack, but I don't have time to pretty this up!
-- Steve
On Fri, 9 Dec 2005, Lee Revell wrote:
>
> $ file init/built-in.o
> init/built-in.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1
> (SYSV), not stripped
>
>> From man gcc, i386 section:
>
> -m32
> -m64
> Generate code for a 32-bit or 64-bit environment. The 32-bit
> environment sets int, long and pointer to 32
> bits and generates code that runs on any i386 system. The
> 64-bit environment sets int to 32 bits and long
> and pointer to 64 bits and generates code for AMD's x86-64
> architecture.
>
> Lee
>
Yes, file shows your gcc does indeed do the right thing with -m64, and
thank you, but I was already familiar with -m64 (to say nothing of
passing LDEMULATION to userspace compilations [info binutils, if you
need to know]).
So, do you have some sort of religious objection to using
CROSS_COMPILE= when building for a processor that doesn't match the
userspace ? And I repeat, messing with CFLAGS should NOT be necessary.
Ken
--
das eine Mal als Trag?die, das andere Mal als Farce
On Fri, 2005-12-09 at 16:25 -0500, Steven Rostedt wrote:
> For my x86_64, I gave up on trying to do it through the normal path
> (having a plain debian unstable system), and finally just downloaded
> the gcc toolchain (gcc, binutils, and glibc) and built them as cross
> compilers with the prefix x86_64-linux-
>
I was trying to avoid that, as the gcc-4.0-x86-64 package has an
unfortunate dependency on a 70MB glibc-cross-x86-64 package which I
almost certainly don't really need to compile the kernel.
So I guess this is a bug in the Ubuntu 5.10 gcc, I'll report it as such.
Thanks,
Lee
On Fri, 2005-12-09 at 21:30 +0000, Ken Moffat wrote:
> On Fri, 9 Dec 2005, Lee Revell wrote:
>
> >
> > $ file init/built-in.o
> > init/built-in.o: ELF 64-bit LSB relocatable, AMD x86-64, version 1
> > (SYSV), not stripped
> >
> >> From man gcc, i386 section:
> >
> > -m32
> > -m64
> > Generate code for a 32-bit or 64-bit environment. The 32-bit
> > environment sets int, long and pointer to 32
> > bits and generates code that runs on any i386 system. The
> > 64-bit environment sets int to 32 bits and long
> > and pointer to 64 bits and generates code for AMD's x86-64
> > architecture.
> >
> > Lee
> >
>
> Yes, file shows your gcc does indeed do the right thing with -m64, and
> thank you, but I was already familiar with -m64 (to say nothing of
> passing LDEMULATION to userspace compilations [info binutils, if you
> need to know]).
>
> So, do you have some sort of religious objection to using
> CROSS_COMPILE= when building for a processor that doesn't match the
> userspace ? And I repeat, messing with CFLAGS should NOT be necessary.
It seems like CROSS_COMPILE= should not be needed if my standard gcc
binary can produce x86-64 code. I was hoping it would be possible to
build an x86-64 kernel using the Ubuntu packages and that I would not
have to resort to building my own toolchain. And it seems that it's
supposed to work, but doesn't.
Lee
On Fri, 9 Dec 2005, Lee Revell wrote:
>
> It seems like CROSS_COMPILE= should not be needed if my standard gcc
> binary can produce x86-64 code. I was hoping it would be possible to
> build an x86-64 kernel using the Ubuntu packages and that I would not
> have to resort to building my own toolchain. And it seems that it's
> supposed to work, but doesn't.
>
Last time I used it, crosstool was painless, but I guess you'd prefer
this link to x86 cross-compilers that akpm posted the other month:
http://developer.osdl.org/dev/plm/cross_compile/
(I haven't tried the x86_64 version there, but the powerpc64 worked a
treat).
--
das eine Mal als Trag?die, das andere Mal als Farce
Lee Revell wrote:
>I'm trying to build an x66-64 kernel on a 32 bit system (Ubuntu 5.10).
>I added -m64 to the CFLAGS as per the gcc docs. But the build fails
>with:
>
>$ make ARCH=x86_64
> [...]
> CC init/initramfs.o
>
>
I have successfully done this using Debian/Sid.
1. I changed the linux/Makefile:
ARCH ?= x86_64
CROSS_COMPILE ?= x86_x64-linux-
2. The I changed the path to include the following /tmp/lin64/ directory:
PATH=/tmp/lin64:$PATH
3. I made a bunch of scripts as follows all in the /tmp/lin64/ directory:
x86_x64-linux-ar:
#!/bin/bash
ar $@
x86_x64-linux-gcc:
#!/bin/bash
has32=`echo "$@" | grep -- "-m32"`
if [ "$has32" = "" ] ; then
gcc -m64 $@
else
gcc $@
fi
x86_x64-linux-ld:
#!/bin/bash
ld -m64 $@
x86_x64-linux-nm:
#!/bin/bash
nm $@
x86_x64-linux-objcopy:
#!/bin/bash
objcopy $@
Le vendredi 09 d?cembre 2005 ? 13:50 -0500, Lee Revell a ?crit :
> I'm trying to build an x66-64 kernel on a 32 bit system (Ubuntu 5.10).
> I added -m64 to the CFLAGS as per the gcc docs.
Under debian 32bits with 64bits kernel, I just add -m64 somewhere in the
main Makefile to rebuild my modules. Didn't try with a whole kernel
though.
Xav
On Fri, 2005-12-09 at 16:37 -0600, Jeffrey Hundstad wrote:
> Lee Revell wrote:
>
> >I'm trying to build an x66-64 kernel on a 32 bit system (Ubuntu 5.10).
> >I added -m64 to the CFLAGS as per the gcc docs. But the build fails
> >with:
> >
> >$ make ARCH=x86_64
> > [...]
> > CC init/initramfs.o
> >
> >
>
> I have successfully done this using Debian/Sid.
>
I added "-m64" to AFLAGS as well and now I get farther:
CC arch/x86_64/ia32/syscall32.o
AS arch/x86_64/ia32/vsyscall-sysenter.o
arch/x86_64/ia32/vsyscall-sysenter.S: Assembler messages:
arch/x86_64/ia32/vsyscall-sysenter.S:14: Error: suffix or operands invalid for `push'
arch/x86_64/ia32/vsyscall-sysenter.S:16: Error: suffix or operands invalid for `push'
arch/x86_64/ia32/vsyscall-sysenter.S:18: Error: suffix or operands invalid for `push'
arch/x86_64/ia32/vsyscall-sysenter.S:25: Error: suffix or operands invalid for `pop'
arch/x86_64/ia32/vsyscall-sysenter.S:27: Error: suffix or operands invalid for `pop'
arch/x86_64/ia32/vsyscall-sysenter.S:29: Error: suffix or operands invalid for `pop'
arch/x86_64/ia32/vsyscall-sigreturn.S:16: Error: suffix or operands invalid for `pop'
make[1]: *** [arch/x86_64/ia32/vsyscall-sysenter.o] Error 1
make: *** [arch/x86_64/ia32] Error 2
Lee
Lee Revell wrote:
>On Fri, 2005-12-09 at 16:37 -0600, Jeffrey Hundstad wrote:
>
>
>>Lee Revell wrote:
>>
>>
>>
>>>I'm trying to build an x66-64 kernel on a 32 bit system (Ubuntu 5.10).
>>>I added -m64 to the CFLAGS as per the gcc docs. But the build fails
>>>with:
>>>
>>>$ make ARCH=x86_64
>>> [...]
>>> CC init/initramfs.o
>>>
>>>
>>>
>>>
>>I have successfully done this using Debian/Sid.
>>
>>
>>
>
>I added "-m64" to AFLAGS as well and now I get farther:
>
> CC arch/x86_64/ia32/syscall32.o
> AS arch/x86_64/ia32/vsyscall-sysenter.o
>arch/x86_64/ia32/vsyscall-sysenter.S: Assembler messages:
>arch/x86_64/ia32/vsyscall-sysenter.S:14: Error: suffix or operands invalid for `push'
>arch/x86_64/ia32/vsyscall-sysenter.S:16: Error: suffix or operands invalid for `push'
>arch/x86_64/ia32/vsyscall-sysenter.S:18: Error: suffix or operands invalid for `push'
>arch/x86_64/ia32/vsyscall-sysenter.S:25: Error: suffix or operands invalid for `pop'
>arch/x86_64/ia32/vsyscall-sysenter.S:27: Error: suffix or operands invalid for `pop'
>arch/x86_64/ia32/vsyscall-sysenter.S:29: Error: suffix or operands invalid for `pop'
>arch/x86_64/ia32/vsyscall-sigreturn.S:16: Error: suffix or operands invalid for `pop'
>make[1]: *** [arch/x86_64/ia32/vsyscall-sysenter.o] Error 1
>make: *** [arch/x86_64/ia32] Error 2
>
>Lee
>
>
>
Yes, some commands NEED the -m64 and and WILL NOT work with -m64.
Really, try my method. I've done it without all that making a separate
binutils non-sense.
You do need the 64-bit Debian build tools and 64 bit libraries. These
are the ones I have:
amd64-libs
amd64-libs-dev
lib64gcc1
lib64gfortran0
lib64ncurses5
lib64ncurses5-dev
lib64objc1
lib64stdc++6
lib64stdc++6-4.0-dbg
lib64z1
lib64z1-dev
libc6-amd64
libc6-dev-amd64
Yes... here's lin64.tar.gz if you didn't catch my little scripts before.
BTW: if there's a better way, please let me know. ...After I got this
to work I kinda quit looking ;-)
--
Jeffrey Hundstad
On Fri, 2005-12-09 at 18:23 -0600, Jeffrey Hundstad wrote:
> Lee Revell wrote:
>
> >On Fri, 2005-12-09 at 16:37 -0600, Jeffrey Hundstad wrote:
> >
> >
> >>Lee Revell wrote:
> >>
> >>
> >>
> >>>I'm trying to build an x66-64 kernel on a 32 bit system (Ubuntu 5.10).
> >>>I added -m64 to the CFLAGS as per the gcc docs. But the build fails
> >>>with:
> >>>
> >>>$ make ARCH=x86_64
> >>> [...]
> >>> CC init/initramfs.o
> >>>
> >>>
> >>>
> >>>
> >>I have successfully done this using Debian/Sid.
> >>
> >>
> >>
> >
> >I added "-m64" to AFLAGS as well and now I get farther:
> >
> > CC arch/x86_64/ia32/syscall32.o
> > AS arch/x86_64/ia32/vsyscall-sysenter.o
> >arch/x86_64/ia32/vsyscall-sysenter.S: Assembler messages:
> >arch/x86_64/ia32/vsyscall-sysenter.S:14: Error: suffix or operands invalid for `push'
> >arch/x86_64/ia32/vsyscall-sysenter.S:16: Error: suffix or operands invalid for `push'
> >arch/x86_64/ia32/vsyscall-sysenter.S:18: Error: suffix or operands invalid for `push'
> >arch/x86_64/ia32/vsyscall-sysenter.S:25: Error: suffix or operands invalid for `pop'
> >arch/x86_64/ia32/vsyscall-sysenter.S:27: Error: suffix or operands invalid for `pop'
> >arch/x86_64/ia32/vsyscall-sysenter.S:29: Error: suffix or operands invalid for `pop'
> >arch/x86_64/ia32/vsyscall-sigreturn.S:16: Error: suffix or operands invalid for `pop'
> >make[1]: *** [arch/x86_64/ia32/vsyscall-sysenter.o] Error 1
> >make: *** [arch/x86_64/ia32] Error 2
> >
> >Lee
> >
> >
> >
>
> Yes, some commands NEED the -m64 and and WILL NOT work with -m64.
>
> Really, try my method. I've done it without all that making a separate
> binutils non-sense.
Your scripts don't help. I still need to add "-m64" to the CFLAGS and
AFLAGS to get it to work at all, otherwise gcc is invoked in 32 bit
mode, and they don't address the problem where some invocations of AS
need -m64 and some like:
AS arch/x86_64/ia32/vsyscall-sysenter.o
need -m32.
Lee
On Fri, 2005-12-09 at 23:43 +0100, Xavier Bestel wrote:
> Le vendredi 09 d?cembre 2005 ? 13:50 -0500, Lee Revell a ?crit :
> > I'm trying to build an x66-64 kernel on a 32 bit system (Ubuntu 5.10).
> > I added -m64 to the CFLAGS as per the gcc docs.
>
> Under debian 32bits with 64bits kernel, I just add -m64 somewhere in the
> main Makefile to rebuild my modules. Didn't try with a whole kernel
> though.
The bug seems to be that the kernel build system does not grok biarch
toolchains - it really insists on a separate toolchain for i386 and
x86_64 even though the situation can be handled with selective use of
-m64. If I jsut add -m64 to everything then it fails when it gets to
the ia32 stuff.
Lee
On Fri, 2005-12-09 at 18:23 -0600, Jeffrey Hundstad wrote:
> Lee Revell wrote:
>
> >On Fri, 2005-12-09 at 16:37 -0600, Jeffrey Hundstad wrote:
> >
> >
> >>Lee Revell wrote:
> >>
> >>
> >>
> >>>I'm trying to build an x66-64 kernel on a 32 bit system (Ubuntu 5.10).
> >>>I added -m64 to the CFLAGS as per the gcc docs. But the build fails
> >>>with:
> >>>
> >>>$ make ARCH=x86_64
> >>> [...]
> >>> CC init/initramfs.o
> >>>
> >>>
> >>>
> >>>
> >>I have successfully done this using Debian/Sid.
> >>
> >>
> >>
> >
> >I added "-m64" to AFLAGS as well and now I get farther:
> >
> > CC arch/x86_64/ia32/syscall32.o
> > AS arch/x86_64/ia32/vsyscall-sysenter.o
> >arch/x86_64/ia32/vsyscall-sysenter.S: Assembler messages:
> >arch/x86_64/ia32/vsyscall-sysenter.S:14: Error: suffix or operands invalid for `push'
> >arch/x86_64/ia32/vsyscall-sysenter.S:16: Error: suffix or operands invalid for `push'
> >arch/x86_64/ia32/vsyscall-sysenter.S:18: Error: suffix or operands invalid for `push'
> >arch/x86_64/ia32/vsyscall-sysenter.S:25: Error: suffix or operands invalid for `pop'
> >arch/x86_64/ia32/vsyscall-sysenter.S:27: Error: suffix or operands invalid for `pop'
> >arch/x86_64/ia32/vsyscall-sysenter.S:29: Error: suffix or operands invalid for `pop'
> >arch/x86_64/ia32/vsyscall-sigreturn.S:16: Error: suffix or operands invalid for `pop'
> >make[1]: *** [arch/x86_64/ia32/vsyscall-sysenter.o] Error 1
> >make: *** [arch/x86_64/ia32] Error 2
> >
> >Lee
> >
> >
> >
>
> Yes, some commands NEED the -m64 and and WILL NOT work with -m64.
>
Aha! I disabled CONFIG_IA32_EMULATION and it works perfectly.
So all that's needed to build an x86_64 kernel with the i386 Ubuntu 5.10
toolchain:
- edit Makefile: add -m64 to CFLAGS and AFLAGS
- disable CONFIG_IA32_EMULATION
- make ARCH=x86_64
Lee
Lee Revell <[email protected]> writes:
> >
> > Yes, some commands NEED the -m64 and and WILL NOT work with -m64.
> >
>
> Aha! I disabled CONFIG_IA32_EMULATION and it works perfectly.
>
> So all that's needed to build an x86_64 kernel with the i386 Ubuntu 5.10
> toolchain:
>
> - edit Makefile: add -m64 to CFLAGS and AFLAGS
I guess I can add that.
I'm surprised someone does such a weird setup. Only the very early
x86-64 distributions set up the gccs like this until it was noticed
that a gcc compiled for 64bit targets run noticeable slower on 32bit
and needs more memory. That's because it does everything with long
long internally then and gcc's code generation for long long is not
exactly great. So it's normally better to use a separate cross
compiler for 64bit to keep the 32bit compilations running faster.
Ubuntu seems didn't pay attention to history and just repated that
mistake. In addition they don't seem to be very fond of contributing
changes back - normally one would expect the distribution maintainer
to submit a patch like this if they set up their gcc in non
traditional this way.
But you're the first to bring this problem to my attention.
> - disable CONFIG_IA32_EMULATION
I just tried it here. Adding -m64 to CFLAGS/AFLAGS on a native
64bit biarch toolchain and it compiled without problems. It ends
up with -m64 -m32 for the 32bit vsyscall files, but that seems
to DTRT at least in gcc 4.
I'm not sure what's going wrong. If you use a freshly unmodified tree
and apply the appended patch does it work for you?
-Andi
Pass -m64 by default
This might help on distributions that use a 32bit biarch compiler.
Signed-off-by: Andi Kleen <[email protected]>
Index: linux/arch/x86_64/Makefile
===================================================================
--- linux.orig/arch/x86_64/Makefile
+++ linux/arch/x86_64/Makefile
@@ -31,6 +31,7 @@ cflags-$(CONFIG_MK8) += $(call cc-option
cflags-$(CONFIG_MPSC) += $(call cc-option,-march=nocona)
CFLAGS += $(cflags-y)
+CFLAGS += -m64
CFLAGS += -mno-red-zone
CFLAGS += -mcmodel=kernel
CFLAGS += -pipe
@@ -52,6 +53,8 @@ CFLAGS += $(call cc-option,-funit-at-a-t
# prevent gcc from generating any FP code by mistake
CFLAGS += $(call cc-option,-mno-sse -mno-mmx -mno-sse2 -mno-3dnow,)
+AFLAGS += -m64
+
head-y := arch/x86_64/kernel/head.o arch/x86_64/kernel/head64.o arch/x86_64/kernel/init_task.o
libs-y += arch/x86_64/lib/
On Sat, 2005-12-10 at 01:56 -0700, Andi Kleen wrote:
> Lee Revell <[email protected]> writes:
> > - disable CONFIG_IA32_EMULATION
>
> I just tried it here. Adding -m64 to CFLAGS/AFLAGS on a native
> 64bit biarch toolchain and it compiled without problems. It ends
> up with -m64 -m32 for the 32bit vsyscall files, but that seems
> to DTRT at least in gcc 4.
Nope, passing -m64 -m32 does not seem to DTRT on native 32bit biarch
toolchain:
make -f scripts/Makefile.build obj=arch/x86_64/ia32
gcc -Wp,-MD,arch/x86_64/ia32/.vsyscall-sysenter.o.d -nostdinc
-isystem /usr/lib/gcc/i486-linux-gnu/4.0.2/include -D__KERNEL__
-Iinclude -D__ASSEMBLY__ -m64 -m32 -c -o
arch/x86_64/ia32/vsyscall-sysenter.o
arch/x86_64/ia32/vsyscall-sysenter.S
arch/x86_64/ia32/vsyscall-sysenter.S: Assembler messages:
arch/x86_64/ia32/vsyscall-sysenter.S:14: Error: suffix or operands
invalid for `push'
etc
That command succeeds if I run it by hand only passing -m32.
Lee
On Sat, Dec 10, 2005 at 12:12:03AM -0500, Lee Revell wrote:
> On Sat, 2005-12-10 at 01:56 -0700, Andi Kleen wrote:
> > Lee Revell <[email protected]> writes:
> > > - disable CONFIG_IA32_EMULATION
> >
> > I just tried it here. Adding -m64 to CFLAGS/AFLAGS on a native
> > 64bit biarch toolchain and it compiled without problems. It ends
> > up with -m64 -m32 for the 32bit vsyscall files, but that seems
> > to DTRT at least in gcc 4.
>
> Nope, passing -m64 -m32 does not seem to DTRT on native 32bit biarch
> toolchain:
How about this patch?
-Andi
Pass -m64 by default
This might help on distributions that use a 32bit biarch compiler.
Signed-off-by: Andi Kleen <[email protected]>
Index: linux/arch/x86_64/Makefile
===================================================================
--- linux.orig/arch/x86_64/Makefile
+++ linux/arch/x86_64/Makefile
@@ -31,6 +31,7 @@ cflags-$(CONFIG_MK8) += $(call cc-option
cflags-$(CONFIG_MPSC) += $(call cc-option,-march=nocona)
CFLAGS += $(cflags-y)
+CFLAGS += -m64
CFLAGS += -mno-red-zone
CFLAGS += -mcmodel=kernel
CFLAGS += -pipe
@@ -52,6 +53,8 @@ CFLAGS += $(call cc-option,-funit-at-a-t
# prevent gcc from generating any FP code by mistake
CFLAGS += $(call cc-option,-mno-sse -mno-mmx -mno-sse2 -mno-3dnow,)
+AFLAGS += -m64
+
head-y := arch/x86_64/kernel/head.o arch/x86_64/kernel/head64.o arch/x86_64/kernel/init_task.o
libs-y += arch/x86_64/lib/
Index: linux/arch/x86_64/ia32/vsyscall-sigreturn.S
===================================================================
--- linux.orig/arch/x86_64/ia32/vsyscall-sigreturn.S
+++ linux/arch/x86_64/ia32/vsyscall-sigreturn.S
@@ -7,6 +7,7 @@
* by doing ".balign 32" must match in both versions of the page.
*/
+ .code32
.section .text.sigreturn,"ax"
.balign 32
.globl __kernel_sigreturn
Index: linux/arch/x86_64/ia32/vsyscall-syscall.S
===================================================================
--- linux.orig/arch/x86_64/ia32/vsyscall-syscall.S
+++ linux/arch/x86_64/ia32/vsyscall-syscall.S
@@ -6,6 +6,7 @@
#include <asm/asm-offsets.h>
#include <asm/segment.h>
+ .code32
.text
.section .text.vsyscall,"ax"
.globl __kernel_vsyscall
Index: linux/arch/x86_64/ia32/vsyscall-sysenter.S
===================================================================
--- linux.orig/arch/x86_64/ia32/vsyscall-sysenter.S
+++ linux/arch/x86_64/ia32/vsyscall-sysenter.S
@@ -5,6 +5,7 @@
#include <asm/ia32_unistd.h>
#include <asm/asm-offsets.h>
+ .code32
.text
.section .text.vsyscall,"ax"
.globl __kernel_vsyscall
On Sat, 2005-12-10 at 08:19 +0100, Andi Kleen wrote:
> On Sat, Dec 10, 2005 at 12:12:03AM -0500, Lee Revell wrote:
> > On Sat, 2005-12-10 at 01:56 -0700, Andi Kleen wrote:
> > > Lee Revell <[email protected]> writes:
> > > > - disable CONFIG_IA32_EMULATION
> > >
> > > I just tried it here. Adding -m64 to CFLAGS/AFLAGS on a native
> > > 64bit biarch toolchain and it compiled without problems. It ends
> > > up with -m64 -m32 for the 32bit vsyscall files, but that seems
> > > to DTRT at least in gcc 4.
> >
> > Nope, passing -m64 -m32 does not seem to DTRT on native 32bit biarch
> > toolchain:
>
> How about this patch?
Yes, works great.
Lee
On Sat, 2005-12-10 at 08:19 +0100, Andi Kleen wrote:
> On Sat, Dec 10, 2005 at 12:12:03AM -0500, Lee Revell wrote:
> > On Sat, 2005-12-10 at 01:56 -0700, Andi Kleen wrote:
> > > Lee Revell <[email protected]> writes:
> > > > - disable CONFIG_IA32_EMULATION
> > >
> > > I just tried it here. Adding -m64 to CFLAGS/AFLAGS on a native
> > > 64bit biarch toolchain and it compiled without problems. It ends
> > > up with -m64 -m32 for the 32bit vsyscall files, but that seems
> > > to DTRT at least in gcc 4.
> >
> > Nope, passing -m64 -m32 does not seem to DTRT on native 32bit biarch
> > toolchain:
>
> How about this patch?
FWIW it still fails at the final link step:
ld -m elf_x86_64 -o .tmp_vmlinux1 -T arch/x86_64/kernel/vmlinux.lds
arch/x86_64/kernel/head.o arch/x86_64/kernel/head64.o
arch/x86_64/kernel/init_task.o init/built-in.o --start-group
usr/built-in.o arch/x86_64/kernel/built-in.o arch/x86_64/mm/built-in.o
arch/x86_64/crypto/built-in.o arch/x86_64/ia32/built-in.o
kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o
security/built-in.o crypto/built-in.o lib/lib.a arch/x86_64/lib/lib.a
lib/built-in.o arch/x86_64/lib/built-in.o drivers/built-in.o
sound/built-in.o arch/x86_64/pci/built-in.o net/built-in.o
--end-group
ld:arch/x86_64/kernel/vmlinux.lds:383: parse error
make: *** [.tmp_vmlinux1] Error 1
Here are the relevant lines of arch/x86_64/kernel/vmlinux.lds:
382 OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
383 OUTPUT_ARCH(1:x86-64)
384 ENTRY(phys_startup_64)
Any ideas? Another toolchain quirk?
Lee
Le vendredi 09 d?cembre 2005 ? 20:31 -0500, Lee Revell a ?crit :
> On Fri, 2005-12-09 at 23:43 +0100, Xavier Bestel wrote:
> > Le vendredi 09 d?cembre 2005 ? 13:50 -0500, Lee Revell a ?crit :
> > > I'm trying to build an x66-64 kernel on a 32 bit system (Ubuntu 5.10).
> > > I added -m64 to the CFLAGS as per the gcc docs.
> >
> > Under debian 32bits with 64bits kernel, I just add -m64 somewhere in the
> > main Makefile to rebuild my modules. Didn't try with a whole kernel
> > though.
>
> The bug seems to be that the kernel build system does not grok biarch
> toolchains - it really insists on a separate toolchain for i386 and
> x86_64 even though the situation can be handled with selective use of
> -m64. If I jsut add -m64 to everything then it fails when it gets to
> the ia32 stuff.
Yes, you shouldn't compile host executables with -m64, obviously.
--- /usr/src/linux-headers-2.6.14-2/Makefile.old 2005-12-10 21:32:17.000000000 +0100
+++ /usr/src/linux-headers-2.6.14-2/Makefile 2005-11-17 14:26:02.000000000 +0100
@@ -352,7 +352,7 @@
CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
-fno-strict-aliasing -fno-common \
- -ffreestanding
+ -ffreestanding -m64
AFLAGS := -D__ASSEMBLY__
export VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION LOCALVERSION KERNELRELEASE \
HTH,
Xav
On Sat, 2005-12-10 at 21:34 +0100, Xavier Bestel wrote:
> Le vendredi 09 d?cembre 2005 ? 20:31 -0500, Lee Revell a ?crit :
> > On Fri, 2005-12-09 at 23:43 +0100, Xavier Bestel wrote:
> > > Le vendredi 09 d?cembre 2005 ? 13:50 -0500, Lee Revell a ?crit :
> > > > I'm trying to build an x66-64 kernel on a 32 bit system (Ubuntu 5.10).
> > > > I added -m64 to the CFLAGS as per the gcc docs.
> > >
> > > Under debian 32bits with 64bits kernel, I just add -m64 somewhere in the
> > > main Makefile to rebuild my modules. Didn't try with a whole kernel
> > > though.
> >
> > The bug seems to be that the kernel build system does not grok biarch
> > toolchains - it really insists on a separate toolchain for i386 and
> > x86_64 even though the situation can be handled with selective use of
> > -m64. If I jsut add -m64 to everything then it fails when it gets to
> > the ia32 stuff.
>
> Yes, you shouldn't compile host executables with -m64, obviously.
>
> --- /usr/src/linux-headers-2.6.14-2/Makefile.old 2005-12-10 21:32:17.000000000 +0100
> +++ /usr/src/linux-headers-2.6.14-2/Makefile 2005-11-17 14:26:02.000000000 +0100
> @@ -352,7 +352,7 @@
>
> CFLAGS := -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs \
> -fno-strict-aliasing -fno-common \
> - -ffreestanding
> + -ffreestanding -m64
> AFLAGS := -D__ASSEMBLY__
>
> export VERSION PATCHLEVEL SUBLEVEL EXTRAVERSION LOCALVERSION KERNELRELEASE \
>
>
> HTH,
This would break native 32 bit kernel builds. Andi's patch seems to be
the correct solution.
Lee
> Here are the relevant lines of arch/x86_64/kernel/vmlinux.lds:
>
> 382 OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
> 383 OUTPUT_ARCH(1:x86-64)
> 384 ENTRY(phys_startup_64)
>
> Any ideas? Another toolchain quirk?
The original is
OUTPUT_ARCH(i386:x86-64)
It replaced the i386 with 1, which obviously doesn't work.
Try (full patch again)
-Andi
Pass -m64 by default
This might help on distributions that use a 32bit biarch compiler.
Also add some more .code32s because at least the Ubuntu biarch
32bit gcc doesn't seem to handle -m64 -m32 as generated
by the Makefile without such assistance.
Signed-off-by: Andi Kleen <[email protected]>
Index: linux/arch/x86_64/Makefile
===================================================================
--- linux.orig/arch/x86_64/Makefile
+++ linux/arch/x86_64/Makefile
@@ -31,6 +31,7 @@ cflags-$(CONFIG_MK8) += $(call cc-option
cflags-$(CONFIG_MPSC) += $(call cc-option,-march=nocona)
CFLAGS += $(cflags-y)
+CFLAGS += -m64
CFLAGS += -mno-red-zone
CFLAGS += -mcmodel=kernel
CFLAGS += -pipe
@@ -52,6 +53,8 @@ CFLAGS += $(call cc-option,-funit-at-a-t
# prevent gcc from generating any FP code by mistake
CFLAGS += $(call cc-option,-mno-sse -mno-mmx -mno-sse2 -mno-3dnow,)
+AFLAGS += -m64
+
head-y := arch/x86_64/kernel/head.o arch/x86_64/kernel/head64.o arch/x86_64/kernel/init_task.o
libs-y += arch/x86_64/lib/
Index: linux/arch/x86_64/ia32/vsyscall-sigreturn.S
===================================================================
--- linux.orig/arch/x86_64/ia32/vsyscall-sigreturn.S
+++ linux/arch/x86_64/ia32/vsyscall-sigreturn.S
@@ -7,6 +7,7 @@
* by doing ".balign 32" must match in both versions of the page.
*/
+ .code32
.section .text.sigreturn,"ax"
.balign 32
.globl __kernel_sigreturn
Index: linux/arch/x86_64/ia32/vsyscall-syscall.S
===================================================================
--- linux.orig/arch/x86_64/ia32/vsyscall-syscall.S
+++ linux/arch/x86_64/ia32/vsyscall-syscall.S
@@ -6,6 +6,7 @@
#include <asm/asm-offsets.h>
#include <asm/segment.h>
+ .code32
.text
.section .text.vsyscall,"ax"
.globl __kernel_vsyscall
Index: linux/arch/x86_64/ia32/vsyscall-sysenter.S
===================================================================
--- linux.orig/arch/x86_64/ia32/vsyscall-sysenter.S
+++ linux/arch/x86_64/ia32/vsyscall-sysenter.S
@@ -5,6 +5,7 @@
#include <asm/ia32_unistd.h>
#include <asm/asm-offsets.h>
+ .code32
.text
.section .text.vsyscall,"ax"
.globl __kernel_vsyscall
Index: linux/arch/x86_64/kernel/vmlinux.lds.S
===================================================================
--- linux.orig/arch/x86_64/kernel/vmlinux.lds.S
+++ linux/arch/x86_64/kernel/vmlinux.lds.S
@@ -8,6 +8,8 @@
#include <asm/page.h>
#include <linux/config.h>
+#undef i386 /* in case the preprocessor is a 32bit one */
+
OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
OUTPUT_ARCH(i386:x86-64)
ENTRY(phys_startup_64)
On Sun, 2005-12-11 at 01:00 +0100, Andi Kleen wrote:
> > Here are the relevant lines of arch/x86_64/kernel/vmlinux.lds:
> >
> > 382 OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
> > 383 OUTPUT_ARCH(1:x86-64)
> > 384 ENTRY(phys_startup_64)
> >
> > Any ideas? Another toolchain quirk?
>
> The original is
>
> OUTPUT_ARCH(i386:x86-64)
>
> It replaced the i386 with 1, which obviously doesn't work.
>
> Try (full patch again)
OK perfect. The build now completes successfully.
Lee
On Sun, 2005-12-11 at 01:00 +0100, Andi Kleen wrote:
> > Here are the relevant lines of arch/x86_64/kernel/vmlinux.lds:
> >
> > 382 OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
> > 383 OUTPUT_ARCH(1:x86-64)
> > 384 ENTRY(phys_startup_64)
> >
> > Any ideas? Another toolchain quirk?
>
> The original is
>
> OUTPUT_ARCH(i386:x86-64)
>
> It replaced the i386 with 1, which obviously doesn't work.
>
> Try (full patch again)
>
It still gives one error, at the final link step:
LD arch/x86_64/boot/compressed/vmlinux
ld: warning: i386:x86-64 architecture of input file
`arch/x86_64/boot/compressed/head.o' is incompatible with i386 output
Lee
On Sun, 2005-12-11 at 01:00 +0100, Andi Kleen wrote:
> > Here are the relevant lines of arch/x86_64/kernel/vmlinux.lds:
> >
> > 382 OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
> > 383 OUTPUT_ARCH(1:x86-64)
> > 384 ENTRY(phys_startup_64)
> >
> > Any ideas? Another toolchain quirk?
>
> The original is
>
> OUTPUT_ARCH(i386:x86-64)
>
> It replaced the i386 with 1, which obviously doesn't work.
>
> Try (full patch again)
>
I still get:
SYSCALL arch/x86_64/ia32/vsyscall-sysenter.so
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`arch/x86_64/ia32/vsyscall-sysenter.o' is incompatible with i386 output
AS arch/x86_64/ia32/vsyscall-syscall.o
SYSCALL arch/x86_64/ia32/vsyscall-syscall.so
/usr/bin/ld: warning: i386:x86-64 architecture of input file
`arch/x86_64/ia32/vsyscall-syscall.o' is incompatible with i386 output
AS arch/x86_64/ia32/syscall32_syscall.o
Lee
On Sun, 2005-12-11 at 01:00 +0100, Andi Kleen wrote:
> > Here are the relevant lines of arch/x86_64/kernel/vmlinux.lds:
> >
> > 382 OUTPUT_FORMAT("elf64-x86-64", "elf64-x86-64", "elf64-x86-64")
> > 383 OUTPUT_ARCH(1:x86-64)
> > 384 ENTRY(phys_startup_64)
> >
> > Any ideas? Another toolchain quirk?
>
> The original is
>
> OUTPUT_ARCH(i386:x86-64)
>
> It replaced the i386 with 1, which obviously doesn't work.
>
> Try (full patch again)
Do you expect these fixes to go into 2.6.16?
Lee
On Wednesday 11 January 2006 17:48, Lee Revell wrote:
> Do you expect these fixes to go into 2.6.16?
Yes.
-Andi