On 28.06.2006 [12:13:21 +0200], Blaisorblade wrote:
> On Wednesday 28 June 2006 02:47, Nishanth Aravamudan wrote:
> > On 27.06.2006 [11:31:28 -0700], Nishanth Aravamudan wrote:
> > > On 27.06.2006 [16:56:13 +0200], Blaisorblade wrote:
> > > > On Tuesday 27 June 2006 00:02, Nishanth Aravamudan wrote:
> > > > > Hi Jeff,
> > > > >
> > > > > I run an x86_64 kernel with i386 userspace (Ubuntu Dapper) and
> > > > > decided to try out UML today. I found that UML wasn't quite
> > > > > aware of biarch compilers (which Ubuntu i386 ships). A fix
> > > > > similar to what was done for x86_64 should probably be
> > > > > committed (see
> > > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=113425940204010&w=2).
> > > >
> > > > Ok, it seemed strange but I understand the stuff... that's very
> > > > interesting as this is the setup I'd wished to have since ages.
> > > > I'll switch to it ASAP...
> > >
> > > Indeed :)
> > >
> > > > > Without the FLAGS changes, the build will fail at a number of
> > > > > places and without the LINK change, the final link will fail.
> > > > >
> > > > > Signed-off-by: Nishanth Aravamudan <nacc@...>
> > > >
> > > > The first hunk (#undef i386) should be unnecessary given you
> > > > specify -m64 (add it to CPPFLAGS too). Also it can/could be
> > > > problematic for
> > Hrm, I somehow overlooked the CPPFLAGS bit. Is it necessary? That
> > wasn't changed for x86_64 and having not changed it for UML, it
> > doesn't appear to have prevented the build from working on both
> > x86_64 and i386 SUBARCHs here.
> It shouldn't go in the general CPPFLAGS indeed. I think that -m64 in
> the preprocessor command used to build vmlinux.lds.S would be cleaner
> than #undef i386... test it by preprocessing by hand and report, I'll
> code the CPPFLAGS_vmlinux.lds.S = -m64 assignment (if it is exactly
> this way) if it works.
Just for clarity's sake, the reason the #undef is there, as far as I can
tell, is otherwise the preprocessor (I'm assuming) goes and makes the
output specification as 1:x86_64 instead of i386:x86_64. If one were
then to go and manually change the 1 to i386 and then reissue make, the
kernel will build just fine.
I removed the #undef i386 from vmlinux.ld.S and added a
CPPFLAGS += -m64
The build completed fine here.
I wonder if a patch against x86_64 to remove the #undef there should
also be applied? I'll take a look.
I run an x86_64 kernel with i386 userspace (Ubuntu Dapper) and decided
to try out UML today. I found that UML wasn't quite aware of biarch
compilers (which Ubuntu i386 ships). A fix similar to what was done for
x86_64 should probably be committed (see
Without the FLAGS changes, the build will fail at a number of places and
without the LINK change, the final link will fail.
This is the patch I'm currently using. I don't know if putting the
CPPFLAGS in the Makefile-x86_64 is bad or not, I'll leave that up to
those with more knowledge to decide.
Signed-off-by: Nishanth Aravamudan <nacc@...>
diff -urpN 2.6.17/arch/um/Makefile-x86_64 2.6.17-dev/arch/um/Makefile-x86_64
--- 2.6.17/arch/um/Makefile-x86_64 2006-06-17 18:49:35.000000000 -0700
+++ 2.6.17-dev/arch/um/Makefile-x86_64 2006-06-29 13:47:22.000000000 -0700
@@ -6,9 +6,12 @@ START := 0x60000000
#We #undef __x86_64__ for kernelspace, not for userspace where
#it's needed for headers to work!
-CFLAGS += -U__$(SUBARCH)__ -fno-builtin
-USER_CFLAGS += -fno-builtin
+CFLAGS += -U__$(SUBARCH)__ -fno-builtin -m64
+USER_CFLAGS += -fno-builtin -m64
CHECKFLAGS += -m64
+AFLAGS += -m64
+LDFLAGS += -m elf_x86_64
+CPPFLAGS += -m64
ELF_ARCH := i386:x86-64
ELF_FORMAT := elf64-x86-64
@@ -16,3 +19,4 @@ ELF_FORMAT := elf64-x86-64
# Not on all 64-bit distros /lib is a symlink to /lib64. PLD is an example.
LINK-$(CONFIG_LD_SCRIPT_DYN) += -Wl,-rpath,/lib64
+LINK-y += -m64
Nishanth Aravamudan <nacc@...>
IBM Linux Technology Center