* linux-next: build failure after merge of most trees @ 2017-06-22 5:24 Stephen Rothwell 2017-06-22 5:49 ` Nicholas Piggin 2017-06-22 8:41 ` Nicholas Piggin 0 siblings, 2 replies; 19+ messages in thread From: Stephen Rothwell @ 2017-06-22 5:24 UTC (permalink / raw) To: David Miller Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Masahiro Yamada, Nicholas Piggin 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees 2017-06-22 5:24 linux-next: build failure after merge of most trees Stephen Rothwell @ 2017-06-22 5:49 ` Nicholas Piggin 2017-06-22 6:20 ` Stephen Rothwell 2017-06-22 8:41 ` Nicholas Piggin 1 sibling, 1 reply; 19+ messages in thread From: Nicholas Piggin @ 2017-06-22 5:49 UTC (permalink / raw) To: Stephen Rothwell Cc: David Miller, Linux-Next Mailing List, Linux Kernel Mailing List, Masahiro Yamada On Thu, 22 Jun 2017 15:24:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees 2017-06-22 5:49 ` Nicholas Piggin @ 2017-06-22 6:20 ` Stephen Rothwell 2017-06-22 6:23 ` Stephen Rothwell 0 siblings, 1 reply; 19+ messages in thread From: Stephen Rothwell @ 2017-06-22 6:20 UTC (permalink / raw) To: Nicholas Piggin Cc: David Miller, Linux-Next Mailing List, Linux Kernel Mailing List, Masahiro Yamada Hi Nicholas, On Thu, 22 Jun 2017 15:49:52 +1000 Nicholas Piggin <npiggin@gmail.com> 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees 2017-06-22 6:20 ` Stephen Rothwell @ 2017-06-22 6:23 ` Stephen Rothwell 0 siblings, 0 replies; 19+ messages in thread From: Stephen Rothwell @ 2017-06-22 6:23 UTC (permalink / raw) To: Nicholas Piggin Cc: David Miller, Linux-Next Mailing List, Linux Kernel Mailing List, Masahiro Yamada Hi Nick, On Thu, 22 Jun 2017 16:20:11 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote: > > On Thu, 22 Jun 2017 15:49:52 +1000 Nicholas Piggin <npiggin@gmail.com> 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees 2017-06-22 5:24 linux-next: build failure after merge of most trees Stephen Rothwell 2017-06-22 5:49 ` Nicholas Piggin @ 2017-06-22 8:41 ` Nicholas Piggin 2017-06-22 14:13 ` David Miller 2017-06-22 14:13 ` Alan Modra 1 sibling, 2 replies; 19+ messages in thread From: Nicholas Piggin @ 2017-06-22 8:41 UTC (permalink / raw) To: Stephen Rothwell Cc: David Miller, Linux-Next Mailing List, Linux Kernel Mailing List, Masahiro Yamada, Alan Modra CC'ing Alan On Thu, 22 Jun 2017 15:24:41 +1000 Stephen Rothwell <sfr@canb.auug.org.au> 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees 2017-06-22 8:41 ` Nicholas Piggin @ 2017-06-22 14:13 ` David Miller 2017-06-22 14:29 ` David Miller 2017-06-22 14:33 ` Nicholas Piggin 2017-06-22 14:13 ` Alan Modra 1 sibling, 2 replies; 19+ messages in thread From: David Miller @ 2017-06-22 14:13 UTC (permalink / raw) To: npiggin; +Cc: sfr, linux-next, linux-kernel, yamada.masahiro, amodra From: Nicholas Piggin <npiggin@gmail.com> 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" ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees 2017-06-22 14:13 ` David Miller @ 2017-06-22 14:29 ` David Miller 2017-06-23 3:40 ` Nicholas Piggin 2017-06-22 14:33 ` Nicholas Piggin 1 sibling, 1 reply; 19+ messages in thread From: David Miller @ 2017-06-22 14:29 UTC (permalink / raw) To: npiggin; +Cc: sfr, linux-next, linux-kernel, yamada.masahiro, amodra From: David Miller <davem@davemloft.net> Date: Thu, 22 Jun 2017 10:13:06 -0400 (EDT) > From: Nicholas Piggin <npiggin@gmail.com> > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees 2017-06-22 14:29 ` David Miller @ 2017-06-23 3:40 ` Nicholas Piggin 0 siblings, 0 replies; 19+ messages in thread From: Nicholas Piggin @ 2017-06-23 3:40 UTC (permalink / raw) To: David Miller; +Cc: sfr, linux-next, linux-kernel, yamada.masahiro, amodra On Thu, 22 Jun 2017 10:29:23 -0400 (EDT) David Miller <davem@davemloft.net> wrote: > From: David Miller <davem@davemloft.net> > Date: Thu, 22 Jun 2017 10:13:06 -0400 (EDT) > > > From: Nicholas Piggin <npiggin@gmail.com> > > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees 2017-06-22 14:13 ` David Miller 2017-06-22 14:29 ` David Miller @ 2017-06-22 14:33 ` Nicholas Piggin 2017-06-22 14:56 ` David Miller 1 sibling, 1 reply; 19+ messages in thread From: Nicholas Piggin @ 2017-06-22 14:33 UTC (permalink / raw) To: David Miller; +Cc: sfr, linux-next, linux-kernel, yamada.masahiro, amodra On Thu, 22 Jun 2017 10:13:06 -0400 (EDT) David Miller <davem@davemloft.net> wrote: > From: Nicholas Piggin <npiggin@gmail.com> > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees 2017-06-22 14:33 ` Nicholas Piggin @ 2017-06-22 14:56 ` David Miller 2017-06-23 3:34 ` Nicholas Piggin 2017-06-23 6:43 ` Stephen Rothwell 0 siblings, 2 replies; 19+ messages in thread From: David Miller @ 2017-06-22 14:56 UTC (permalink / raw) To: npiggin; +Cc: sfr, linux-next, linux-kernel, yamada.masahiro, amodra From: Nicholas Piggin <npiggin@gmail.com> Date: Fri, 23 Jun 2017 00:33:39 +1000 > On Thu, 22 Jun 2017 10:13:06 -0400 (EDT) > David Miller <davem@davemloft.net> wrote: > >> From: Nicholas Piggin <npiggin@gmail.com> >> 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 <davem@davemloft.net> 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" ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees 2017-06-22 14:56 ` David Miller @ 2017-06-23 3:34 ` Nicholas Piggin 2017-06-23 6:43 ` Stephen Rothwell 1 sibling, 0 replies; 19+ messages in thread From: Nicholas Piggin @ 2017-06-23 3:34 UTC (permalink / raw) To: David Miller; +Cc: sfr, linux-next, linux-kernel, yamada.masahiro, amodra On Thu, 22 Jun 2017 10:56:48 -0400 (EDT) David Miller <davem@davemloft.net> wrote: > From: Nicholas Piggin <npiggin@gmail.com> > Date: Fri, 23 Jun 2017 00:33:39 +1000 > > > On Thu, 22 Jun 2017 10:13:06 -0400 (EDT) > > David Miller <davem@davemloft.net> wrote: > > > >> From: Nicholas Piggin <npiggin@gmail.com> > >> 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 <davem@davemloft.net> Thanks for the patch, looks good to me. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees 2017-06-22 14:56 ` David Miller 2017-06-23 3:34 ` Nicholas Piggin @ 2017-06-23 6:43 ` Stephen Rothwell 2017-06-23 6:46 ` yamada.masahiro 1 sibling, 1 reply; 19+ messages in thread From: Stephen Rothwell @ 2017-06-23 6:43 UTC (permalink / raw) To: David Miller; +Cc: npiggin, linux-next, linux-kernel, yamada.masahiro, amodra Hi all, On Thu, 22 Jun 2017 10:56:48 -0400 (EDT) David Miller <davem@davemloft.net> 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 <davem@davemloft.net> > > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: linux-next: build failure after merge of most trees 2017-06-23 6:43 ` Stephen Rothwell @ 2017-06-23 6:46 ` yamada.masahiro 0 siblings, 0 replies; 19+ messages in thread From: yamada.masahiro @ 2017-06-23 6:46 UTC (permalink / raw) To: sfr, davem; +Cc: npiggin, linux-next, linux-kernel, amodra Hi Stephen, > -----Original Message----- > From: Stephen Rothwell [mailto:sfr@canb.auug.org.au] > Sent: Friday, June 23, 2017 3:43 PM > To: David Miller <davem@davemloft.net> > Cc: npiggin@gmail.com; linux-next@vger.kernel.org; > linux-kernel@vger.kernel.org; Yamada, Masahiro/山田 真弘 > <yamada.masahiro@socionext.com>; amodra@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 <davem@davemloft.net> > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* RE: linux-next: build failure after merge of most trees @ 2017-06-23 6:46 ` yamada.masahiro 0 siblings, 0 replies; 19+ messages in thread From: yamada.masahiro @ 2017-06-23 6:46 UTC (permalink / raw) To: sfr, davem; +Cc: npiggin, linux-next, linux-kernel, amodra Hi Stephen, > -----Original Message----- > From: Stephen Rothwell [mailto:sfr@canb.auug.org.au] > Sent: Friday, June 23, 2017 3:43 PM > To: David Miller <davem@davemloft.net> > Cc: npiggin@gmail.com; linux-next@vger.kernel.org; > linux-kernel@vger.kernel.org; Yamada, Masahiro/山田 真弘 > <yamada.masahiro@socionext.com>; amodra@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 <davem@davemloft.net> > 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. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees 2017-06-23 6:46 ` yamada.masahiro @ 2017-06-23 7:04 ` Stephen Rothwell -1 siblings, 0 replies; 19+ messages in thread From: Stephen Rothwell @ 2017-06-23 7:04 UTC (permalink / raw) To: yamada.masahiro; +Cc: davem, npiggin, linux-next, linux-kernel, amodra Hi, On Fri, 23 Jun 2017 06:46:53 +0000 <yamada.masahiro@socionext.com> wrote: > > > -----Original Message----- > > From: Stephen Rothwell [mailto:sfr@canb.auug.org.au] > > Sent: Friday, June 23, 2017 3:43 PM > > To: David Miller <davem@davemloft.net> > > Cc: npiggin@gmail.com; linux-next@vger.kernel.org; > > linux-kernel@vger.kernel.org; Yamada, Masahiro/山田 真弘 > > <yamada.masahiro@socionext.com>; amodra@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 <davem@davemloft.net> > > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees @ 2017-06-23 7:04 ` Stephen Rothwell 0 siblings, 0 replies; 19+ messages in thread From: Stephen Rothwell @ 2017-06-23 7:04 UTC (permalink / raw) To: yamada.masahiro; +Cc: davem, npiggin, linux-next, linux-kernel, amodra Hi, On Fri, 23 Jun 2017 06:46:53 +0000 <yamada.masahiro@socionext.com> wrote: > > > -----Original Message----- > > From: Stephen Rothwell [mailto:sfr@canb.auug.org.au] > > Sent: Friday, June 23, 2017 3:43 PM > > To: David Miller <davem@davemloft.net> > > Cc: npiggin@gmail.com; linux-next@vger.kernel.org; > > linux-kernel@vger.kernel.org; Yamada, Masahiro/山田 真弘 > > <yamada.masahiro@socionext.com>; amodra@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 <davem@davemloft.net> > > 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees 2017-06-23 6:46 ` yamada.masahiro (?) (?) @ 2017-06-23 15:13 ` David Miller -1 siblings, 0 replies; 19+ messages in thread From: David Miller @ 2017-06-23 15:13 UTC (permalink / raw) To: yamada.masahiro; +Cc: sfr, npiggin, linux-next, linux-kernel, amodra From: <yamada.masahiro@socionext.com> Date: Fri, 23 Jun 2017 06:46:53 +0000 > I will insert this before Nicholas' series. Thank you. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees 2017-06-22 8:41 ` Nicholas Piggin 2017-06-22 14:13 ` David Miller @ 2017-06-22 14:13 ` Alan Modra 2017-06-22 14:43 ` Nicholas Piggin 1 sibling, 1 reply; 19+ messages in thread From: Alan Modra @ 2017-06-22 14:13 UTC (permalink / raw) To: Nicholas Piggin Cc: Stephen Rothwell, David Miller, Linux-Next Mailing List, Linux Kernel Mailing List, Masahiro Yamada 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: linux-next: build failure after merge of most trees 2017-06-22 14:13 ` Alan Modra @ 2017-06-22 14:43 ` Nicholas Piggin 0 siblings, 0 replies; 19+ messages in thread From: Nicholas Piggin @ 2017-06-22 14:43 UTC (permalink / raw) To: Alan Modra Cc: Stephen Rothwell, David Miller, Linux-Next Mailing List, Linux Kernel Mailing List, Masahiro Yamada On Thu, 22 Jun 2017 23:43:10 +0930 Alan Modra <amodra@gmail.com> 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 ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2017-06-23 15:13 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-06-22 5:24 linux-next: build failure after merge of most trees Stephen Rothwell 2017-06-22 5:49 ` Nicholas Piggin 2017-06-22 6:20 ` Stephen Rothwell 2017-06-22 6:23 ` Stephen Rothwell 2017-06-22 8:41 ` Nicholas Piggin 2017-06-22 14:13 ` David Miller 2017-06-22 14:29 ` David Miller 2017-06-23 3:40 ` Nicholas Piggin 2017-06-22 14:33 ` Nicholas Piggin 2017-06-22 14:56 ` David Miller 2017-06-23 3:34 ` Nicholas Piggin 2017-06-23 6:43 ` Stephen Rothwell 2017-06-23 6:46 ` yamada.masahiro 2017-06-23 6:46 ` yamada.masahiro 2017-06-23 7:04 ` Stephen Rothwell 2017-06-23 7:04 ` Stephen Rothwell 2017-06-23 15:13 ` David Miller 2017-06-22 14:13 ` Alan Modra 2017-06-22 14:43 ` Nicholas Piggin
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.