Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1672311 > unrolled thread

linux-next: build failure after merge of most trees

Back to article view | Back to linux.kernel

Contents

  linux-next: build failure after merge of most trees Stephen Rothwell <sfr@canb.auug.org.au> - 2017-06-22 07:30 +0200
    Re: linux-next: build failure after merge of most trees Nicholas Piggin <npiggin@gmail.com> - 2017-06-22 08:00 +0200
      Re: linux-next: build failure after merge of most trees Stephen Rothwell <sfr@canb.auug.org.au> - 2017-06-22 08:30 +0200
      Re: linux-next: build failure after merge of most trees Stephen Rothwell <sfr@canb.auug.org.au> - 2017-06-22 08:30 +0200
    Re: linux-next: build failure after merge of most trees Nicholas Piggin <npiggin@gmail.com> - 2017-06-22 10:50 +0200
      Re: linux-next: build failure after merge of most trees David Miller <davem@davemloft.net> - 2017-06-22 16:20 +0200
        Re: linux-next: build failure after merge of most trees David Miller <davem@davemloft.net> - 2017-06-22 16:30 +0200
          Re: linux-next: build failure after merge of most trees Nicholas Piggin <npiggin@gmail.com> - 2017-06-23 05:50 +0200
        Re: linux-next: build failure after merge of most trees Nicholas Piggin <npiggin@gmail.com> - 2017-06-22 16:40 +0200
          Re: linux-next: build failure after merge of most trees David Miller <davem@davemloft.net> - 2017-06-22 17:00 +0200
            Re: linux-next: build failure after merge of most trees Nicholas Piggin <npiggin@gmail.com> - 2017-06-23 05:40 +0200
            RE: linux-next: build failure after merge of most trees <yamada.masahiro@socionext.com> - 2017-06-23 08:50 +0200
              Re: linux-next: build failure after merge of most trees Stephen Rothwell <sfr@canb.auug.org.au> - 2017-06-23 09:10 +0200
              Re: linux-next: build failure after merge of most trees David Miller <davem@davemloft.net> - 2017-06-23 17:20 +0200
            Re: linux-next: build failure after merge of most trees Stephen Rothwell <sfr@canb.auug.org.au> - 2017-06-23 08:50 +0200
      Re: linux-next: build failure after merge of most trees Alan Modra <amodra@gmail.com> - 2017-06-22 16:20 +0200
        Re: linux-next: build failure after merge of most trees Nicholas Piggin <npiggin@gmail.com> - 2017-06-22 16:50 +0200

#1672311 — 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

[toc] | [next] | [standalone]

#1672317

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

[toc] | [prev] | [next] | [standalone]

#1672332

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

[toc] | [prev] | [next] | [standalone]

#1672333

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

[toc] | [prev] | [next] | [standalone]

#1672427

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

[toc] | [prev] | [next] | [standalone]

#1672659

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"

[toc] | [prev] | [next] | [standalone]

#1672674

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.

[toc] | [prev] | [next] | [standalone]

#1673203

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

[toc] | [prev] | [next] | [standalone]

#1672697

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

[toc] | [prev] | [next] | [standalone]

#1672721

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"

[toc] | [prev] | [next] | [standalone]

#1673201

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.

[toc] | [prev] | [next] | [standalone]

#1673295

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.

[toc] | [prev] | [next] | [standalone]

#1673303

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

[toc] | [prev] | [next] | [standalone]

#1673631

From: <yamada.masahiro@socionext.com>
Date: Fri, 23 Jun 2017 06:46:53 +0000

> I will insert this before Nicholas' series.

Thank you.

[toc] | [prev] | [next] | [standalone]

#1673299

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

[toc] | [prev] | [next] | [standalone]

#1672662

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

[toc] | [prev] | [next] | [standalone]

#1672699

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web