| Message ID | 20160806201045.GA25821@ravnborg.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Sam, On Sat, 6 Aug 2016 22:10:45 +0200 Sam Ravnborg <sam@ravnborg.org> wrote: > > Did you by any chance evalue the use of INPUT in linker files. > Stephen back then (again based on proposal from Alan Modra), > also made an implementation using INPUT. The problem with that idea was that (at least for some versions of binutils in use at the time) we hit a static limit to the number of object files and ld just stopped at that point. :-( > See below for an updated simple patch on top of mainline. So, I guess it was fixed, but do we know in what version?
On Sun, Aug 07, 2016 at 11:49:46AM +1000, Stephen Rothwell wrote: > Hi Sam, > > On Sat, 6 Aug 2016 22:10:45 +0200 Sam Ravnborg <sam@ravnborg.org> wrote: > > > > Did you by any chance evalue the use of INPUT in linker files. > > Stephen back then (again based on proposal from Alan Modra), > > also made an implementation using INPUT. > > The problem with that idea was that (at least for some versions of > binutils in use at the time) we hit a static limit to the number of > object files and ld just stopped at that point. :-( > > > See below for an updated simple patch on top of mainline. > > So, I guess it was fixed, but do we know in what version? I think the patch was https://sourceware.org/ml/binutils/2012-06/msg00201.html So, you need binutils 2.23 or later.
On Sun, 7 Aug 2016, Stephen Rothwell wrote: > Hi Sam, > > On Sat, 6 Aug 2016 22:10:45 +0200 Sam Ravnborg <sam@ravnborg.org> wrote: > > > > Did you by any chance evalue the use of INPUT in linker files. > > Stephen back then (again based on proposal from Alan Modra), > > also made an implementation using INPUT. > > The problem with that idea was that (at least for some versions of > binutils in use at the time) we hit a static limit to the number of > object files and ld just stopped at that point. :-( I played with a nearly identical patch to work around the inability to do LTO and 'ld -r' with mainline binutils. However this also requires major changes to modpost otherwise it becomes ineffective. Nicolas -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, 6 Aug 2016 22:10:45 +0200 Sam Ravnborg <sam@ravnborg.org> wrote: > Hi Nicholas. > > On Fri, Aug 05, 2016 at 10:11:59PM +1000, Nicholas Piggin wrote: > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > > > ld -r is an incremental link used to create built-in.o files in build > > subdirectories. It produces relocatable object files containing all > > its input files, and these are are then pulled together and relocated > > in the final link. Aside from the bloat, this constrains the final > > link relocations, which has bitten large powerpc builds with > > unresolvable relocations in the final link. > > > > Alan Modra has recommended the kernel use thin archives for linking. > > This is an alternative and means that the linker has more information > > available to it when it links the kernel. > > > > This patch enables a config option architectures can select, > If we want to do this, then I suggest to make the logic reverse. > Architectures that for some reasons cannot use this should > have the possibility to avoid it. But let it be enabled by default. I was thinking the build matrix (architectures x build options x toolchains) is a bit too large to switch it for everybody. I've far from even tested it for a fraction of powerpc builds. I would prefer arch maintainers to switch it themselves, but I do hope we can move everybody and just remove the old method within a few releases. But I'm happy to go with whatever arch and kbuild maintainers prefer, so I appreciate any discussion on it. Thanks, Nick -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Monday, August 8, 2016 1:25:32 PM CEST Nicholas Piggin wrote: > On Sat, 6 Aug 2016 22:10:45 +0200 > Sam Ravnborg <sam@ravnborg.org> wrote: > > > Hi Nicholas. > > > > On Fri, Aug 05, 2016 at 10:11:59PM +1000, Nicholas Piggin wrote: > > > From: Stephen Rothwell <sfr@canb.auug.org.au> > > > > > > ld -r is an incremental link used to create built-in.o files in build > > > subdirectories. It produces relocatable object files containing all > > > its input files, and these are are then pulled together and relocated > > > in the final link. Aside from the bloat, this constrains the final > > > link relocations, which has bitten large powerpc builds with > > > unresolvable relocations in the final link. > > > > > > Alan Modra has recommended the kernel use thin archives for linking. > > > This is an alternative and means that the linker has more information > > > available to it when it links the kernel. > > > > > > This patch enables a config option architectures can select, > > If we want to do this, then I suggest to make the logic reverse. > > Architectures that for some reasons cannot use this should > > have the possibility to avoid it. But let it be enabled by default. > > I was thinking the build matrix (architectures x build options x toolchains) > is a bit too large to switch it for everybody. I've far from even tested it > for a fraction of powerpc builds. I would prefer arch maintainers to switch > it themselves, but I do hope we can move everybody and just remove the old > method within a few releases. > > But I'm happy to go with whatever arch and kbuild maintainers prefer, so I > appreciate any discussion on it. How about making the option visible for everyone with CONFIG_EXPERT? That way you don't get it by default, but you do get it with randconfig and allmodconfig build testing. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/scripts/Makefile.build b/scripts/Makefile.build index 11602e5..954e7cb 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -360,10 +360,9 @@ $(sort $(subdir-obj-y)): $(subdir-ym) ; ifdef builtin-target quiet_cmd_link_o_target = LD $@ # If the list of objects to link is empty, just create an empty built-in.o -cmd_link_o_target = $(if $(strip $(obj-y)),\ - $(LD) $(ld_flags) -r -o $@ $(filter $(obj-y), $^) \ - $(cmd_secanalysis),\ - rm -f $@; $(AR) rcs$(KBUILD_ARFLAGS) $@) +cmd_link_o_target = $(if $(filter $(obj-y), $^), \ + echo INPUT\($(filter $(obj-y), $^)\) > $@, \ + echo "/* empty */" > $@) $(builtin-target): $(obj-y) FORCE $(call if_changed,link_o_target) @@ -414,10 +413,10 @@ $($(subst $(obj)/,,$(@:.o=-y))) \ $($(subst $(obj)/,,$(@:.o=-m)))), $^) quiet_cmd_link_multi-y = LD $@ -cmd_link_multi-y = $(LD) $(ld_flags) -r -o $@ $(link_multi_deps) $(cmd_secanalysis) +cmd_link_multi-y = echo INPUT\($(link_multi_deps)\) > $@ quiet_cmd_link_multi-m = LD [M] $@ -cmd_link_multi-m = $(cmd_link_multi-y) +cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(link_multi_deps) $(multi-used-y): FORCE $(call if_changed,link_multi-y)