[kbuild-devel] Re: UML kbuild patch
Hello! On Mon, Sep 23, 2002 at 07:24:01PM -0500, Kai Germaschewski wrote: > I just thought of another solution, which actually seems cleaner and has > less impact on the top-level (generic) Makefile. On a little bit unrelated note, I found that your changes accepted by Linus broke UML (the ones entitled as 'kbuild: arch/um cleanup / O_TARGET removal') build for 2.5.38, so that's what I was forced to do to make it to compile: = arch/um/Makefile 1.3 vs edited = --- 1.3/arch/um/MakefileTue Sep 24 15:37:03 2002 +++ edited/arch/um/Makefile Tue Sep 24 16:12:46 2002 @@ -30,15 +30,10 @@ LINK_PROFILE = $(PROFILE) -Wl,--wrap,__monstartup endif -ARCH_SUBDIRS = $(ARCH_DIR)/drivers $(ARCH_DIR)/kernel \ - $(ARCH_DIR)/sys-$(SUBARCH) $(ARCH_DIR)/os-$(OS) - -SUBDIRS += $(ARCH_SUBDIRS) - core-y += $(ARCH_DIR)/kernel/ \ - += $(ARCH_DIR)/drivers/ \ - += $(ARCH_DIR)/sys-$(SUBARCH)/ \ - += $(ARCH_DIR)/os-$(OS)/ + $(ARCH_DIR)/drivers/ \ + $(ARCH_DIR)/sys-$(SUBARCH)/ \ + $(ARCH_DIR)/os-$(OS)/ libs-$(CONFIG_PT_PROXY)+= $(ARCH_DIR)/ptproxy/ @@ -63,7 +58,9 @@ -DELF_ARCH=$(ELF_ARCH) -DELF_FORMAT=\"$(ELF_FORMAT)\" LD_vmlinux = $(CC) -LDFLAGS_vmlinux = $(LINK_PROFILE) $(LINK_WRAPS) -static $(ARCH_DIR)/main.o +LDFLAGS_vmlinux = $(LINK_PROFILE) $(LINK_WRAPS) -static $(ARCH_DIR)/main.o -L/usr/lib + +LIBS += -lutil SYMLINK_HEADERS = include/asm-um/archparam.h include/asm-um/system.h \ include/asm-um/sigcontext.h include/asm-um/processor.h \ = arch/um/Makefile-os-Linux 1.1 vs edited = --- 1.1/arch/um/Makefile-os-Linux Fri Sep 6 21:29:28 2002 +++ edited/arch/um/Makefile-os-LinuxTue Sep 24 15:56:31 2002 @@ -4,4 +4,3 @@ # SUBDIRS += $(ARCH_DIR)/os-$(OS)/drivers -LIBS += $(ARCH_DIR)/os-$(OS)/drivers/drivers.o = arch/um/kernel/Makefile 1.2 vs edited = --- 1.2/arch/um/kernel/Makefile Mon Sep 23 03:40:07 2002 +++ edited/arch/um/kernel/Makefile Tue Sep 24 15:49:48 2002 @@ -10,7 +10,6 @@ umid.o user_util.o obj-$(CONFIG_BLK_DEV_INITRD) += initrd_kern.o initrd_user.o -endif # user_syms.o not included here because Rules.make has its own ideas about # building anything in export-objs --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: UML kbuild patch
[Removed l-k Cc] On Mon, 23 Sep 2002, Jeff Dike wrote: > [EMAIL PROTECTED] said: > > The actual executable UML generates is called "linux" anyway, so its > > Makefile can have its own rule (as for other archs the boot images) > > which builds "linux" from "vmlinux" using gcc and the link script. - > > I.e. the same way as UML used to do it earlier, anyway. > > I'd actually prefer the one-stage link. That takes better advantage of > the infrastructure that you've put in place. > > Instead of making LDFLAGS_vmlinux available to the arch Makefile, can > you make cmd_link_vmlinux available? Then I can just rewrite it. > > That looks like it has no impact on the global Makefile except for moving > it above the include of the arch Makefile. Well, I don't think messing with cmd_link_vmlinux yourself is a good idea, that basically means code duplication, which is bad ;) If you really want the one-stage link, let's do it the way you suggested. However, I still think doing vmlinux first and linux afterwards is conceptually more similar to the normal vmlinux -> bzImage or whatever. For example, there's a pending patch (kksymoops/kallsyms) which replaces the vmlinux link with a two-stage process, it'd be nice if such changes can happen without interfering with arch/*/Makefile at all. So here's my current proposal, however I'm not entirely sure if that order of using the link script is okay or not, uml just segfaults here either way. Against your updates-2.5. --Kai = Makefile 1.308 vs edited = --- 1.308/Makefile Mon Sep 23 20:46:21 2002 +++ edited/Makefile Tue Sep 24 11:32:18 2002 @@ -288,12 +288,10 @@ # we cannot yet know if we will need to relink vmlinux. # So we descend into init/ inside the rule for vmlinux again. -LD_vmlinux := $(if $(LD_vmlinux),$(LD_vmlinux),$(LD)) - vmlinux-objs := $(HEAD) $(INIT) $(CORE_FILES) $(LIBS) $(DRIVERS) $(NETWORKS) quiet_cmd_link_vmlinux = LD $@ -cmd_link_vmlinux = $(LD_vmlinux) $(LDFLAGS_$(@F)) $(HEAD) $(INIT) \ +cmd_link_vmlinux = $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) $(HEAD) $(INIT) \ --start-group \ $(CORE_FILES) \ $(LIBS) \ @@ -315,11 +313,7 @@ $(NM) vmlinux | grep -v '\(compiled\)\|\(\.o$$\)\|\( [aUw] \)\|\(\.\.ng$$\)\|\(LASH[RL]DI\)' | sort > System.map endef -LDFLAGS_vmlinux_default = -T arch/$(ARCH)/vmlinux.lds.s -LDFLAGS_vmlinux_gcc = -Wl,-T,arch/$(ARCH)/vmlinux.lds.s - -vmlinux_base = $(basename $(notdir $(LD_vmlinux))) -LDFLAGS_vmlinux += $(if $(LDFLAGS_vmlinux_$(vmlinux_base)),$(LDFLAGS_vmlinux_$(vmlinux_base)),$(LDFLAGS_vmlinux_default)) +LDFLAGS_vmlinux += -T arch/$(ARCH)/vmlinux.lds.s vmlinux: $(vmlinux-objs) arch/$(ARCH)/vmlinux.lds.s FORCE $(call if_changed_rule,link_vmlinux) = arch/um/Makefile 1.3 vs edited = --- 1.3/arch/um/MakefileMon Sep 23 20:51:25 2002 +++ edited/arch/um/Makefile Tue Sep 24 11:50:42 2002 @@ -32,8 +32,7 @@ core-y += $(ARCH_DIR)/kernel/ \ $(ARCH_DIR)/drivers/ \ - $(ARCH_DIR)/sys-$(SUBARCH)/ \ - $(ARCH_DIR)/os-$(OS)/ + $(ARCH_DIR)/sys-$(SUBARCH)/ libs-$(CONFIG_PT_PROXY)+= $(ARCH_DIR)/ptproxy/ @@ -48,8 +47,6 @@ -DSUBARCH=\"$(SUBARCH)\" -D_LARGEFILE64_SOURCE -I$(ARCH_INCLUDE) \ -Derrno=kernel_errno -LDFLAGS += -r - LINK_WRAPS = -Wl,--wrap,malloc -Wl,--wrap,free -Wl,--wrap,calloc SIZE = (($(CONFIG_NEST_LEVEL) + $(CONFIG_KERNEL_HALF_GIGS)) * 0x2000) @@ -57,8 +54,7 @@ AFLAGS_vmlinux.lds.o = -U$(SUBARCH) -DSTART=$$(($(TOP_ADDR) - $(SIZE))) \ -DELF_ARCH=$(ELF_ARCH) -DELF_FORMAT=\"$(ELF_FORMAT)\" -LD_vmlinux = $(CC) -LDFLAGS_vmlinux = $(LINK_PROFILE) $(LINK_WRAPS) -static $(ARCH_DIR)/main.o +LDFLAGS_vmlinux = -r $(LINK_PROFILE) -static $(ARCH_DIR)/main.o SYMLINK_HEADERS = include/asm-um/archparam.h include/asm-um/system.h \ include/asm-um/sigcontext.h include/asm-um/processor.h \ @@ -72,7 +68,7 @@ linux: scripts $(ARCH_SYMLINKS) $(GEN_HEADERS) $(SYS_HEADERS) \ $(ARCH_DIR)/main.o \ vmlinux - mv vmlinux linux + gcc -o $@ $(LINK_WRAPS) -lutil vmlinux USER_CFLAGS := $(patsubst -I%,,$(CFLAGS)) USER_CFLAGS := $(patsubst -Derrno=kernel_errno,,$(USER_CFLAGS)) = arch/um/Makefile-os-Linux 1.1 vs edited = --- 1.1/arch/um/Makefile-os-Linux Fri Sep 6 12:29:28 2002 +++ edited/arch/um/Makefile-os-LinuxTue Sep 24 11:44:02 2002 @@ -3,5 +3,4 @@ # Licensed under the GPL # -SUBDIRS += $(ARCH_DIR)/os-$(OS)/drivers -LIBS += $(ARCH_DIR)/os-$(OS)/drivers/drivers.o +core-y += $(ARCH_DIR)/os-$(OS)/ = arch/um/kernel/Makefile 1.2 vs edited = --- 1.2/arch/um/kernel/Makefile Sun Sep 22 18:40:07 2002 +++ edited/arch/um/kernel/Makefile Tue Sep 24 11:36:03 2002 @@ -10,7 +10,6 @@ umid.o user_util.o obj-$(CONFIG_BLK_DEV_INITRD) += initrd_kern.o initrd
[kbuild-devel] Re: UML kbuild patch
[EMAIL PROTECTED] said: > The actual executable UML generates is called "linux" anyway, so its > Makefile can have its own rule (as for other archs the boot images) > which builds "linux" from "vmlinux" using gcc and the link script. - > I.e. the same way as UML used to do it earlier, anyway. I'd actually prefer the one-stage link. That takes better advantage of the infrastructure that you've put in place. Instead of making LDFLAGS_vmlinux available to the arch Makefile, can you make cmd_link_vmlinux available? Then I can just rewrite it. That looks like it has no impact on the global Makefile except for moving it above the include of the arch Makefile. Jeff --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
[kbuild-devel] Re: UML kbuild patch
On Mon, 23 Sep 2002, Jeff Dike wrote: > The UML build needs a few kbuild changes in order to work with the latest > stuff. > > Since kbuild now enforces the use of the linker script on the vmlinux build, > UML can't use its old two-stage link, where > vmlinux is a normal relocatable object file > which is linked into the linux binary with the linker script > > So, in order to fold those into one stage and produce an ELF binary, I need > the vmlinux "linker" to actually be gcc. This implies I need a > "-Wl,-T,arch/$(ARCH)/vmlinux.lds.s" instead of the usual > "-T arch/$(ARCH)/vmlinux.lds.s". > > This is done without breaking the other arches by changing the final link > command to $(LD_vmlinux) which is defaulted to $(LD) if the arch doesn't > define it. > > The "-Wl,..." is done similarly by using $(LDFLAGS_vmlinux_default) if > the linker command is anything but gcc and $(LDFLAGS_vmlinux_gcc) if it is > gcc. I just thought of another solution, which actually seems cleaner and has less impact on the top-level (generic) Makefile. Let's just do the LDFLAGS_vmlinux := -T arch/$(ARCH)/vmlinux.lds.s before including arch/$(ARCH)/Makefile. Normal archs can then just do LDFLAGS_vmlinux += -extra_option while UML does LDFLAGS_vmlinux := -r The actual executable UML generates is called "linux" anyway, so its Makefile can have its own rule (as for other archs the boot images) which builds "linux" from "vmlinux" using gcc and the link script. - I.e. the same way as UML used to do it earlier, anyway. The only impact on generic code is basically s/LDFLAGS_vmlinux :=/LDFLAGS_vmlinux +=/ in arch/*/Makefile, and it makes the UML "linux" build conceptually similar to other archs' "bzImage" or whatever targets. What do you think? --Kai --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ kbuild-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/kbuild-devel
