From: Nishanth A. <na...@us...> - 2006-06-26 22:02:34
|
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). 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 <na...@us...> diff -urpN 2.6.17/arch/um/kernel/vmlinux.lds.S 2.6.17-dev/arch/um/kernel/vmlinux.lds.S --- 2.6.17/arch/um/kernel/vmlinux.lds.S 2006-06-17 18:49:35.000000000 -0700 +++ 2.6.17-dev/arch/um/kernel/vmlinux.lds.S 2006-06-26 14:55:45.000000000 -0700 @@ -1,4 +1,5 @@ #include <linux/config.h> +#undef i386 #ifdef CONFIG_LD_SCRIPT_STATIC #include "uml.lds.S" #else 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-26 14:49:01.000000000 -0700 @@ -6,9 +6,11 @@ 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 ELF_ARCH := i386:x86-64 ELF_FORMAT := elf64-x86-64 @@ -16,3 +18,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 <na...@us...> IBM Linux Technology Center |
From: Blaisorblade <bla...@ya...> - 2006-06-27 14:57:17
|
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... > 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 <na...@us...> The first hunk (#undef i386) should be unnecessary given you specify -m64 (add it to CPPFLAGS too). Also it can/could be problematic for i386 kernels. However, if UML builds and runs on already supported configurations, the patch is almost ok - but the original comment must be added for the #undef: /* in case the preprocessor is a 32bit one */ > diff -urpN 2.6.17/arch/um/kernel/vmlinux.lds.S > 2.6.17-dev/arch/um/kernel/vmlinux.lds.S --- > 2.6.17/arch/um/kernel/vmlinux.lds.S 2006-06-17 18:49:35.000000000 -0700 +++ > 2.6.17-dev/arch/um/kernel/vmlinux.lds.S 2006-06-26 14:55:45.000000000 -0700 > @@ -1,4 +1,5 @@ > #include <linux/config.h> > +#undef i386 > #ifdef CONFIG_LD_SCRIPT_STATIC > #include "uml.lds.S" > #else > 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-26 14:49:01.000000000 -0700 @@ > -6,9 +6,11 @@ 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 > > ELF_ARCH := i386:x86-64 > ELF_FORMAT := elf64-x86-64 > @@ -16,3 +18,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 -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
From: Nishanth A. <na...@us...> - 2006-06-27 18:31:38
|
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 <na...@us...> > > The first hunk (#undef i386) should be unnecessary given you specify > -m64 (add it to CPPFLAGS too). Also it can/could be problematic for > i386 kernels. However, if UML builds and runs on already supported > configurations, the patch is almost ok - but the original comment must > be added for the #undef: /* in case the preprocessor is a 32bit one */ Ah yes, sorry, I'll add the comment. I found if I did not add the #undef, I got a broken build (the "1:x86_64" issue in the above thread, when it should be "i386:x86_64"): LD .tmp_vmlinux1 /usr/bin/ld:arch/um/kernel/vmlinux.lds:251: syntax error collect2: ld returned 1 exit status KSYM .tmp_kallsyms1.S nm: '.tmp_vmlinux1': No such file No valid symbol. After discovering SUBARCH, I rebuilt my tree as an i386 UML and it successfully completed with this patch. If someone could test a native i386 build as well, just to be sure? Updated patch follows. 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). Without the FLAGS changes, the build will fail at a number of places and without the LINK change, the final link will fail. Compile- and boot-tested with SUBARCH=x86_64 (native) and compile-tested and boot-tested with SUBARCH=i386. Signed-off-by: Nishanth Aravamudan <na...@us...> diff -urpN 2.6.17/arch/um/kernel/vmlinux.lds.S 2.6.17-dev/arch/um/kernel/vmlinux.lds.S --- 2.6.17/arch/um/kernel/vmlinux.lds.S 2006-06-17 18:49:35.000000000 -0700 +++ 2.6.17-dev/arch/um/kernel/vmlinux.lds.S 2006-06-27 08:03:43.000000000 -0700 @@ -1,4 +1,6 @@ #include <linux/config.h> +/* in case the preprocessor is a 32bit one */ +#undef i386 #ifdef CONFIG_LD_SCRIPT_STATIC #include "uml.lds.S" #else 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-26 14:49:01.000000000 -0700 @@ -6,9 +6,11 @@ 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 ELF_ARCH := i386:x86-64 ELF_FORMAT := elf64-x86-64 @@ -16,3 +18,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 <na...@us...> IBM Linux Technology Center |
From: Nishanth A. <na...@us...> - 2006-06-28 00:48:09
|
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 <na...@us...> > > > > 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. Thanks, Nish -- Nishanth Aravamudan <na...@us...> IBM Linux Technology Center |
From: Jeff D. <jd...@ad...> - 2006-06-28 02:11:27
|
On Tue, Jun 27, 2006 at 11:31:28AM -0700, Nishanth Aravamudan wrote: > After discovering SUBARCH, I rebuilt my tree as an i386 UML and it > successfully completed with this patch. If someone could test a native > i386 build as well, just to be sure? > > Updated patch follows. How updated? I don't see any difference except for the new comment, which I fail to see fixing anything :-) Jeff |
From: Nishanth A. <na...@us...> - 2006-06-28 02:54:17
|
On 27.06.2006 [22:11:31 -0400], Jeff Dike wrote: > On Tue, Jun 27, 2006 at 11:31:28AM -0700, Nishanth Aravamudan wrote: > > After discovering SUBARCH, I rebuilt my tree as an i386 UML and it > > successfully completed with this patch. If someone could test a native > > i386 build as well, just to be sure? > > > > Updated patch follows. > > How updated? I don't see any difference except for the new comment, > which I fail to see fixing anything :-) I added the comment that Blaisorblade asked for, that's it. I didn't realize anything needed to be fixed? Removing the #undef causes the build to fail, so it's necessary, hence the comment. If you'd prefer a more verbose comment to that effect, I can do that, I guess. Did I miss something? Thanks, Nish -- Nishanth Aravamudan <na...@us...> IBM Linux Technology Center |
From: Jeff D. <jd...@ad...> - 2006-06-28 03:43:45
|
On Tue, Jun 27, 2006 at 07:54:07PM -0700, Nishanth Aravamudan wrote: > Did I miss something? Nope, I misread your mail. You described a problem (which had been fixed in the original patch), followed by "updated patch here", leading me to believe there was something fixed in it. nevermind... Jeff |
From: Nishanth A. <na...@us...> - 2006-06-28 03:50:49
|
On 27.06.2006 [23:43:39 -0400], Jeff Dike wrote: > On Tue, Jun 27, 2006 at 07:54:07PM -0700, Nishanth Aravamudan wrote: > > Did I miss something? > > Nope, I misread your mail. You described a problem (which had been > fixed in the original patch), followed by "updated patch here", > leading me to believe there was something fixed in it. > > nevermind... Ah, sorry about that :) Thanks, Nish -- Nishanth Aravamudan <na...@us...> IBM Linux Technology Center |
From: Blaisorblade <bla...@ya...> - 2006-06-28 10:14:11
|
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 <na...@us...> > > > > > > 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. Anyway, this is minor refinement, the patch is otherwise ok. -- Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!". Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894) http://www.user-mode-linux.org/~blaisorblade Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
From: Nishanth A. <na...@us...> - 2006-06-29 20:56:32
|
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 <na...@us...> > > > > > > > > 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 to arch/um/Makefile-x86_64 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. Thanks, Nish --- 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). 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 <na...@us...> 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 <na...@us...> IBM Linux Technology Center |
From: Paolo G. <bla...@ya...> - 2006-06-30 00:29:57
|
Nishanth Aravamudan <na...@us...> ha scritto: > On 28.06.2006 [12:13:21 +0200], Blaisorblade wrote: > 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. I can confirm this is also what I understood. > I removed the #undef i386 from vmlinux.ld.S and added a > > CPPFLAGS += -m64 > > to arch/um/Makefile-x86_64 > The build completed fine here. Yep, that's ok too (and shouldn't hurt for the rest - we'll get -m64 twice for .c files but it shouldn't be a problem; I thought to make it specific it only for vmlinux.lds.S to avoid the duplication). > I wonder if a patch against x86_64 to remove the #undef there > should > also be applied? I'll take a look. Probably it can, and IMHO it's cleaner. For me the patch is now perfect; Jeff please update the one in -mm. > Thanks, > Nish Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com |
From: Jeff D. <jd...@ad...> - 2006-06-30 01:05:36
|
On Fri, Jun 30, 2006 at 02:29:48AM +0200, Paolo Giarrusso wrote: > Probably it can, and IMHO it's cleaner. For me the patch is now > perfect; Jeff please update the one in -mm. Yeah, I'll send an update. Jeff |
From: Nishanth A. <na...@us...> - 2006-06-29 21:49:34
|
On 29.06.2006 [13:56:26 -0700], Nishanth Aravamudan wrote: > 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 <na...@us...> > > > > > > > > > > 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. <snip my e-mail sent before I saw Jeff had sent on the previous patch> An incremental patch for Blaisorblade's idea follows. It builds successfully here. --- On top of the previous biarch changes for UML, this makes the preprocessor changes a bit cleaner. Specify the 64-bit build in CPPFLAGS on the x86_64 SUBARCH, rather than #undef'ing i386. Compile-tested with i386 and x86_64 SUBARCHs. Signed-off-by: Nishanth Aravamudan <na...@us...> diff -urpN 2.6.17-dev2/arch/um/kernel/vmlinux.lds.S 2.6.17-dev/arch/um/kernel/vmlinux.lds.S --- 2.6.17-dev2/arch/um/kernel/vmlinux.lds.S 2006-06-29 14:44:44.000000000 -0700 +++ 2.6.17-dev/arch/um/kernel/vmlinux.lds.S 2006-06-29 13:52:10.000000000 -0700 @@ -1,6 +1,4 @@ #include <linux/config.h> -/* in case the preprocessor is a 32bit one */ -#undef i386 #ifdef CONFIG_LD_SCRIPT_STATIC #include "uml.lds.S" #else diff -urpN 2.6.17-dev2/arch/um/Makefile-x86_64 2.6.17-dev/arch/um/Makefile-x86_64 --- 2.6.17-dev2/arch/um/Makefile-x86_64 2006-06-29 14:44:54.000000000 -0700 +++ 2.6.17-dev/arch/um/Makefile-x86_64 2006-06-29 13:47:22.000000000 -0700 @@ -11,6 +11,7 @@ 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 -- Nishanth Aravamudan <na...@us...> IBM Linux Technology Center |
From: Jeff D. <jd...@ad...> - 2006-07-07 00:52:32
|
On Thu, Jun 29, 2006 at 02:49:24PM -0700, Nishanth Aravamudan wrote: > An incremental patch for Blaisorblade's idea follows. It builds > successfully here. OK, that's in my tree, and I'll be sending it Linus-wards. Jeff |