Re: linux-next: build failure after merge of most trees
From: Date: Fri, 23 Jun 2017 06:46:53 + > I will insert this before Nicholas' series. Thank you.
Re: linux-next: build failure after merge of most trees
Hi, On Fri, 23 Jun 2017 06:46:53 + wrote: > > > -Original Message- > > From: Stephen Rothwell [mailto:s...@canb.auug.org.au] > > Sent: Friday, June 23, 2017 3:43 PM > > To: David Miller > > Cc: npig...@gmail.com; linux-n...@vger.kernel.org; > > linux-kernel@vger.kernel.org; Yamada, Masahiro/山田 真弘 > > ; amo...@gmail.com > > Subject: Re: linux-next: build failure after merge of most trees > > > > Hi all, > > > > On Thu, 22 Jun 2017 10:56:48 -0400 (EDT) David Miller > > wrote: > > > > > > Feel free to merge it into your series: > > > > > > > [snip] > > > > I added that to linux-next today and it fixed the build problem. > > Thanks for taking care of this. No worries. > Sorry, I missed to pick up this for today's release. > I will insert this before Nicholas' series. Thanks, I will drop it on Monday. -- Cheers, Stephen Rothwell
RE: linux-next: build failure after merge of most trees
Hi Stephen, > -Original Message- > From: Stephen Rothwell [mailto:s...@canb.auug.org.au] > Sent: Friday, June 23, 2017 3:43 PM > To: David Miller > Cc: npig...@gmail.com; linux-n...@vger.kernel.org; > linux-kernel@vger.kernel.org; Yamada, Masahiro/山田 真弘 > ; amo...@gmail.com > Subject: Re: linux-next: build failure after merge of most trees > > Hi all, > > On Thu, 22 Jun 2017 10:56:48 -0400 (EDT) David Miller > wrote: > > > > Feel free to merge it into your series: > > > > [snip] > > I added that to linux-next today and it fixed the build problem. Thanks for taking care of this. Sorry, I missed to pick up this for today's release. I will insert this before Nicholas' series.
Re: linux-next: build failure after merge of most trees
Hi all, On Thu, 22 Jun 2017 10:56:48 -0400 (EDT) David Miller wrote: > > Feel free to merge it into your series: > > > sparc64: Use indirect calls in hamming weight stubs. > > Otherwise, depending upon link order, the branch relocation > limits could be exceeded. > > Signed-off-by: David S. Miller > > diff --git a/arch/sparc/lib/hweight.S b/arch/sparc/lib/hweight.S > index f9985f1..d21cf20 100644 > --- a/arch/sparc/lib/hweight.S > +++ b/arch/sparc/lib/hweight.S > @@ -4,9 +4,9 @@ > .text > .align 32 > ENTRY(__arch_hweight8) > - ba,pt %xcc, __sw_hweight8 > + sethi %hi(__sw_hweight8), %g1 > + jmpl%g1 + %lo(__sw_hweight8), %g0 >nop > - nop > ENDPROC(__arch_hweight8) > EXPORT_SYMBOL(__arch_hweight8) > .section.popc_3insn_patch, "ax" > @@ -17,9 +17,9 @@ EXPORT_SYMBOL(__arch_hweight8) > .previous > > ENTRY(__arch_hweight16) > - ba,pt %xcc, __sw_hweight16 > + sethi %hi(__sw_hweight16), %g1 > + jmpl%g1 + %lo(__sw_hweight16), %g0 >nop > - nop > ENDPROC(__arch_hweight16) > EXPORT_SYMBOL(__arch_hweight16) > .section.popc_3insn_patch, "ax" > @@ -30,9 +30,9 @@ EXPORT_SYMBOL(__arch_hweight16) > .previous > > ENTRY(__arch_hweight32) > - ba,pt %xcc, __sw_hweight32 > + sethi %hi(__sw_hweight32), %g1 > + jmpl%g1 + %lo(__sw_hweight32), %g0 >nop > - nop > ENDPROC(__arch_hweight32) > EXPORT_SYMBOL(__arch_hweight32) > .section.popc_3insn_patch, "ax" > @@ -43,9 +43,9 @@ EXPORT_SYMBOL(__arch_hweight32) > .previous > > ENTRY(__arch_hweight64) > - ba,pt %xcc, __sw_hweight64 > + sethi %hi(__sw_hweight16), %g1 > + jmpl%g1 + %lo(__sw_hweight16), %g0 >nop > - nop > ENDPROC(__arch_hweight64) > EXPORT_SYMBOL(__arch_hweight64) > .section.popc_3insn_patch, "ax" I added that to linux-next today and it fixed the build problem. -- Cheers, Stephen Rothwell
Re: linux-next: build failure after merge of most trees
On Thu, 22 Jun 2017 10:29:23 -0400 (EDT) David Miller wrote: > From: David Miller > Date: Thu, 22 Jun 2017 10:13:06 -0400 (EDT) > > > From: Nicholas Piggin > > Date: Thu, 22 Jun 2017 18:41:16 +1000 > > > >> Is there any way for the linker to place the inputs to avoid unresolvable > >> relocations where possible? > > > > I don't think so. > > > >> A way to work around this is to make arch/sparc/lib/hweight.o an obj-y > >> rather than lib-y. That's a hack because it just serves to move the > >> input location, but not really any more of a hack than the current code > >> that also only works because of input locations... > > > > I could adjust those branches in the sparc code into indirect calls > > but it's going to perform a bit poorly on older cpus. > > > > Something like this: > > I just wanted to mention something in passing. > > On sparc64 we patch the first two instructions of memcpy, memset, > bzero, etc. in order to vector them to cpu optimized routines. > > And we use the same kind of branch there. > > Now because the branches are to routines in the same directory it > should never exceed the relocation limits. > > However, if the relocation limits were exceeded in this case, the > build would still succeed and the kernel would be simply broken and > not bootup properly. Powerpc has similar problems with linking, particularly in patch code. What it does is to actually link the patch code into the kernel as well in another section, so the branch target is resolved by the linker. When moving the patch code at runtime, the branch offset is adjusted. So it does get a link error if things don't work there. I guess the other thing you could do is a build-time check over your patch code with a custom script or tool. If you're in the same directory it should be okay, unless it is split between obj-y/built-in.o and lib-y/lib.a then you might have a problem. Thanks, Nick
Re: linux-next: build failure after merge of most trees
On Thu, 22 Jun 2017 10:56:48 -0400 (EDT) David Miller wrote: > From: Nicholas Piggin > Date: Fri, 23 Jun 2017 00:33:39 +1000 > > > On Thu, 22 Jun 2017 10:13:06 -0400 (EDT) > > David Miller wrote: > > > >> From: Nicholas Piggin > >> Date: Thu, 22 Jun 2017 18:41:16 +1000 > >> > >> > Is there any way for the linker to place the inputs to avoid unresolvable > >> > relocations where possible? > >> > >> I don't think so. > >> > >> > A way to work around this is to make arch/sparc/lib/hweight.o an obj-y > >> > rather than lib-y. That's a hack because it just serves to move the > >> > input location, but not really any more of a hack than the current code > >> > that also only works because of input locations... > >> > >> I could adjust those branches in the sparc code into indirect calls > >> but it's going to perform a bit poorly on older cpus. > > > > The build succeeds with your patch. That should solve it properly > > so it won't come back to bite again. > > > > If you can tolerate the slowdown on old CPUs I'd be grateful if > > we could merge it for linux-next to get this thin archives tree > > unblocked. > > Feel free to merge it into your series: > > > sparc64: Use indirect calls in hamming weight stubs. > > Otherwise, depending upon link order, the branch relocation > limits could be exceeded. > > Signed-off-by: David S. Miller Thanks for the patch, looks good to me.
Re: linux-next: build failure after merge of most trees
From: Nicholas Piggin Date: Fri, 23 Jun 2017 00:33:39 +1000 > On Thu, 22 Jun 2017 10:13:06 -0400 (EDT) > David Miller wrote: > >> From: Nicholas Piggin >> Date: Thu, 22 Jun 2017 18:41:16 +1000 >> >> > Is there any way for the linker to place the inputs to avoid unresolvable >> > relocations where possible? >> >> I don't think so. >> >> > A way to work around this is to make arch/sparc/lib/hweight.o an obj-y >> > rather than lib-y. That's a hack because it just serves to move the >> > input location, but not really any more of a hack than the current code >> > that also only works because of input locations... >> >> I could adjust those branches in the sparc code into indirect calls >> but it's going to perform a bit poorly on older cpus. > > The build succeeds with your patch. That should solve it properly > so it won't come back to bite again. > > If you can tolerate the slowdown on old CPUs I'd be grateful if > we could merge it for linux-next to get this thin archives tree > unblocked. Feel free to merge it into your series: sparc64: Use indirect calls in hamming weight stubs. Otherwise, depending upon link order, the branch relocation limits could be exceeded. Signed-off-by: David S. Miller diff --git a/arch/sparc/lib/hweight.S b/arch/sparc/lib/hweight.S index f9985f1..d21cf20 100644 --- a/arch/sparc/lib/hweight.S +++ b/arch/sparc/lib/hweight.S @@ -4,9 +4,9 @@ .text .align 32 ENTRY(__arch_hweight8) - ba,pt %xcc, __sw_hweight8 + sethi %hi(__sw_hweight8), %g1 + jmpl%g1 + %lo(__sw_hweight8), %g0 nop - nop ENDPROC(__arch_hweight8) EXPORT_SYMBOL(__arch_hweight8) .section.popc_3insn_patch, "ax" @@ -17,9 +17,9 @@ EXPORT_SYMBOL(__arch_hweight8) .previous ENTRY(__arch_hweight16) - ba,pt %xcc, __sw_hweight16 + sethi %hi(__sw_hweight16), %g1 + jmpl%g1 + %lo(__sw_hweight16), %g0 nop - nop ENDPROC(__arch_hweight16) EXPORT_SYMBOL(__arch_hweight16) .section.popc_3insn_patch, "ax" @@ -30,9 +30,9 @@ EXPORT_SYMBOL(__arch_hweight16) .previous ENTRY(__arch_hweight32) - ba,pt %xcc, __sw_hweight32 + sethi %hi(__sw_hweight32), %g1 + jmpl%g1 + %lo(__sw_hweight32), %g0 nop - nop ENDPROC(__arch_hweight32) EXPORT_SYMBOL(__arch_hweight32) .section.popc_3insn_patch, "ax" @@ -43,9 +43,9 @@ EXPORT_SYMBOL(__arch_hweight32) .previous ENTRY(__arch_hweight64) - ba,pt %xcc, __sw_hweight64 + sethi %hi(__sw_hweight16), %g1 + jmpl%g1 + %lo(__sw_hweight16), %g0 nop - nop ENDPROC(__arch_hweight64) EXPORT_SYMBOL(__arch_hweight64) .section.popc_3insn_patch, "ax"
Re: linux-next: build failure after merge of most trees
On Thu, 22 Jun 2017 23:43:10 +0930 Alan Modra wrote: > On Thu, Jun 22, 2017 at 06:41:16PM +1000, Nicholas Piggin wrote: > > Is there any way for the linker to place the inputs to avoid unresolvable > > relocations where possible? > > Not without quite a lot of work writing support for that feature. > Okay, just wondering if I'd missed something. It'd probably wouldn't be enough benefit to justify a significant amount of work. We'd be better off looking at link time optimisation if we wanted to go that way. Thanks, Nick
Re: linux-next: build failure after merge of most trees
On Thu, 22 Jun 2017 10:13:06 -0400 (EDT) David Miller wrote: > From: Nicholas Piggin > Date: Thu, 22 Jun 2017 18:41:16 +1000 > > > Is there any way for the linker to place the inputs to avoid unresolvable > > relocations where possible? > > I don't think so. > > > A way to work around this is to make arch/sparc/lib/hweight.o an obj-y > > rather than lib-y. That's a hack because it just serves to move the > > input location, but not really any more of a hack than the current code > > that also only works because of input locations... > > I could adjust those branches in the sparc code into indirect calls > but it's going to perform a bit poorly on older cpus. The build succeeds with your patch. That should solve it properly so it won't come back to bite again. If you can tolerate the slowdown on old CPUs I'd be grateful if we could merge it for linux-next to get this thin archives tree unblocked. Thanks, Nick
Re: linux-next: build failure after merge of most trees
From: David Miller Date: Thu, 22 Jun 2017 10:13:06 -0400 (EDT) > From: Nicholas Piggin > Date: Thu, 22 Jun 2017 18:41:16 +1000 > >> Is there any way for the linker to place the inputs to avoid unresolvable >> relocations where possible? > > I don't think so. > >> A way to work around this is to make arch/sparc/lib/hweight.o an obj-y >> rather than lib-y. That's a hack because it just serves to move the >> input location, but not really any more of a hack than the current code >> that also only works because of input locations... > > I could adjust those branches in the sparc code into indirect calls > but it's going to perform a bit poorly on older cpus. > > Something like this: I just wanted to mention something in passing. On sparc64 we patch the first two instructions of memcpy, memset, bzero, etc. in order to vector them to cpu optimized routines. And we use the same kind of branch there. Now because the branches are to routines in the same directory it should never exceed the relocation limits. However, if the relocation limits were exceeded in this case, the build would still succeed and the kernel would be simply broken and not bootup properly.
Re: linux-next: build failure after merge of most trees
On Thu, Jun 22, 2017 at 06:41:16PM +1000, Nicholas Piggin wrote: > Is there any way for the linker to place the inputs to avoid unresolvable > relocations where possible? Not without quite a lot of work writing support for that feature. -- Alan Modra Australia Development Lab, IBM
Re: linux-next: build failure after merge of most trees
From: Nicholas Piggin Date: Thu, 22 Jun 2017 18:41:16 +1000 > Is there any way for the linker to place the inputs to avoid unresolvable > relocations where possible? I don't think so. > A way to work around this is to make arch/sparc/lib/hweight.o an obj-y > rather than lib-y. That's a hack because it just serves to move the > input location, but not really any more of a hack than the current code > that also only works because of input locations... I could adjust those branches in the sparc code into indirect calls but it's going to perform a bit poorly on older cpus. Something like this: diff --git a/arch/sparc/lib/hweight.S b/arch/sparc/lib/hweight.S index f9985f1..d21cf20 100644 --- a/arch/sparc/lib/hweight.S +++ b/arch/sparc/lib/hweight.S @@ -4,9 +4,9 @@ .text .align 32 ENTRY(__arch_hweight8) - ba,pt %xcc, __sw_hweight8 + sethi %hi(__sw_hweight8), %g1 + jmpl%g1 + %lo(__sw_hweight8), %g0 nop - nop ENDPROC(__arch_hweight8) EXPORT_SYMBOL(__arch_hweight8) .section.popc_3insn_patch, "ax" @@ -17,9 +17,9 @@ EXPORT_SYMBOL(__arch_hweight8) .previous ENTRY(__arch_hweight16) - ba,pt %xcc, __sw_hweight16 + sethi %hi(__sw_hweight16), %g1 + jmpl%g1 + %lo(__sw_hweight16), %g0 nop - nop ENDPROC(__arch_hweight16) EXPORT_SYMBOL(__arch_hweight16) .section.popc_3insn_patch, "ax" @@ -30,9 +30,9 @@ EXPORT_SYMBOL(__arch_hweight16) .previous ENTRY(__arch_hweight32) - ba,pt %xcc, __sw_hweight32 + sethi %hi(__sw_hweight32), %g1 + jmpl%g1 + %lo(__sw_hweight32), %g0 nop - nop ENDPROC(__arch_hweight32) EXPORT_SYMBOL(__arch_hweight32) .section.popc_3insn_patch, "ax" @@ -43,9 +43,9 @@ EXPORT_SYMBOL(__arch_hweight32) .previous ENTRY(__arch_hweight64) - ba,pt %xcc, __sw_hweight64 + sethi %hi(__sw_hweight16), %g1 + jmpl%g1 + %lo(__sw_hweight16), %g0 nop - nop ENDPROC(__arch_hweight64) EXPORT_SYMBOL(__arch_hweight64) .section.popc_3insn_patch, "ax"
Re: linux-next: build failure after merge of most trees
CC'ing Alan On Thu, 22 Jun 2017 15:24:41 +1000 Stephen Rothwell wrote: > Hi Dave, > > After merging almost all the trees, today's linux-next build (sparc64 > defconfig) failed like this: > > arch/sparc/lib/hweight.o: In function `__arch_hweight8': > (.text+0x0): relocation truncated to fit: R_SPARC_WDISP19 against symbol > `__sw_hweight8' defined in .text section in lib/hweight.o > arch/sparc/lib/hweight.o: In function `__arch_hweight16': > (.text+0xc): relocation truncated to fit: R_SPARC_WDISP19 against symbol > `__sw_hweight16' defined in .text section in lib/hweight.o > arch/sparc/lib/hweight.o: In function `__arch_hweight32': > (.text+0x18): relocation truncated to fit: R_SPARC_WDISP19 against symbol > `__sw_hweight32' defined in .text section in lib/hweight.o > arch/sparc/lib/hweight.o: In function `__arch_hweight64': > (.text+0x24): relocation truncated to fit: R_SPARC_WDISP19 against symbol > `__sw_hweight64' defined in .text section in lib/hweight.o After a bit of digging, this is due to that thin archives patch, but only because it changes the order of linker inputs around slightly. You can reproduce it with upstream kernel: This is the final link which succeeds: sparc64-linux-gnu-ld -m elf64_sparc --build-id -o vmlinux -T ./arch/sparc/kernel/vmlinux.lds arch/sparc/kernel/head_64.o init/built-in.o --start-group usr/built-in.o arch/sparc/built-in.o kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/lib.a arch/sparc/prom/lib.a arch/sparc/lib/lib.a lib/built-in.o arch/sparc/prom/built-in.o arch/sparc/lib/built-in.o drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o virt/built-in.o --end-group .tmp_kallsyms2.o Moving the lib.a files to the end: sparc64-linux-gnu-ld -m elf64_sparc --build-id -o vmlinux -T ./arch/sparc/kernel/vmlinux.lds arch/sparc/kernel/head_64.o init/built-in.o --start-group usr/built-in.o arch/sparc/built-in.o kernel/built-in.o certs/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o lib/built-in.o arch/sparc/prom/built-in.o arch/sparc/lib/built-in.o drivers/built-in.o sound/built-in.o firmware/built-in.o net/built-in.o virt/built-in.o lib/lib.a arch/sparc/prom/lib.a arch/sparc/lib/lib.a --end-group .tmp_kallsyms2.o arch/sparc/lib/lib.a(hweight.o): In function `__arch_hweight8': (.text+0x0): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight8' defined in .text section in lib/built-in.o If we also move lib/built-in.o to the end, then the error goes away. Is there any way for the linker to place the inputs to avoid unresolvable relocations where possible? A way to work around this is to make arch/sparc/lib/hweight.o an obj-y rather than lib-y. That's a hack because it just serves to move the input location, but not really any more of a hack than the current code that also only works because of input locations... Any thoughts? Thanks, Nick
Re: linux-next: build failure after merge of most trees
Hi Nick, On Thu, 22 Jun 2017 16:20:11 +1000 Stephen Rothwell wrote: > > On Thu, 22 Jun 2017 15:49:52 +1000 Nicholas Piggin wrote: > > > > It could be this > > > > https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=thin-ar&id=ec2c9c20f0efab37ae31de44fe0617aa61283905 > > > > kbuild: handle libs-y archives separately from built-in.o archives > > > > That touches the lib linking code regardless of CONFIG_THIN_ARCHIVE. > > You should be able to revert it by itself (which will break a few > > other archs, so you would also have to revert the default y patch > > for thin archives to repair your tree if this is the cause). > > Yeah, reverting that commit fixes the sparc64 build. (i have not done > that in today;s linux-next release, however). But it broke the 32 bit sparc defconfig: arch/sparc/lib/strlen.o: In function `strlen': (.text+0x0): multiple definition of `strlen' lib/string.o:string.c:(.text+0x4b4): first defined here No unexpected, I expect :-) -- Cheers, Stephen Rothwell
Re: linux-next: build failure after merge of most trees
Hi Nicholas, On Thu, 22 Jun 2017 15:49:52 +1000 Nicholas Piggin wrote: > > It could be this > > https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=thin-ar&id=ec2c9c20f0efab37ae31de44fe0617aa61283905 > > kbuild: handle libs-y archives separately from built-in.o archives > > That touches the lib linking code regardless of CONFIG_THIN_ARCHIVE. > You should be able to revert it by itself (which will break a few > other archs, so you would also have to revert the default y patch > for thin archives to repair your tree if this is the cause). Yeah, reverting that commit fixes the sparc64 build. (i have not done that in today;s linux-next release, however). > I'll try to get around to it after I fix up some other arch breakage > caused by the series :) Thanks. -- Cheers, Stephen Rothwell
Re: linux-next: build failure after merge of most trees
On Thu, 22 Jun 2017 15:24:41 +1000 Stephen Rothwell wrote: > Hi Dave, > > After merging almost all the trees, today's linux-next build (sparc64 > defconfig) failed like this: > > arch/sparc/lib/hweight.o: In function `__arch_hweight8': > (.text+0x0): relocation truncated to fit: R_SPARC_WDISP19 against symbol > `__sw_hweight8' defined in .text section in lib/hweight.o > arch/sparc/lib/hweight.o: In function `__arch_hweight16': > (.text+0xc): relocation truncated to fit: R_SPARC_WDISP19 against symbol > `__sw_hweight16' defined in .text section in lib/hweight.o > arch/sparc/lib/hweight.o: In function `__arch_hweight32': > (.text+0x18): relocation truncated to fit: R_SPARC_WDISP19 against symbol > `__sw_hweight32' defined in .text section in lib/hweight.o > arch/sparc/lib/hweight.o: In function `__arch_hweight64': > (.text+0x24): relocation truncated to fit: R_SPARC_WDISP19 against symbol > `__sw_hweight64' defined in .text section in lib/hweight.o > > I though it may have been caused by the thin archive changes, but > disabling CONFIG_THIN_ARCHIVE did not fix it. I have cc'd Nick and > Masahiro just in case. It could be this https://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git/commit/?h=thin-ar&id=ec2c9c20f0efab37ae31de44fe0617aa61283905 kbuild: handle libs-y archives separately from built-in.o archives That touches the lib linking code regardless of CONFIG_THIN_ARCHIVE. You should be able to revert it by itself (which will break a few other archs, so you would also have to revert the default y patch for thin archives to repair your tree if this is the cause). I'll try to get around to it after I fix up some other arch breakage caused by the series :) Thanks, Nick
linux-next: build failure after merge of most trees
Hi Dave, After merging almost all the trees, today's linux-next build (sparc64 defconfig) failed like this: arch/sparc/lib/hweight.o: In function `__arch_hweight8': (.text+0x0): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight8' defined in .text section in lib/hweight.o arch/sparc/lib/hweight.o: In function `__arch_hweight16': (.text+0xc): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight16' defined in .text section in lib/hweight.o arch/sparc/lib/hweight.o: In function `__arch_hweight32': (.text+0x18): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight32' defined in .text section in lib/hweight.o arch/sparc/lib/hweight.o: In function `__arch_hweight64': (.text+0x24): relocation truncated to fit: R_SPARC_WDISP19 against symbol `__sw_hweight64' defined in .text section in lib/hweight.o I though it may have been caused by the thin archive changes, but disabling CONFIG_THIN_ARCHIVE did not fix it. I have cc'd Nick and Masahiro just in case. I am using powerpc-le hosted cross compilers: gcc 5.2.0 binutsila 2.25.2 I have left it broken for now. 32 bit sparc is not affected. -- Cheers, Stephen Rothwell