Re: linux-next: build failure after merge of most trees

[David Miller]

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

[David Miller]

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

[Stephen Rothwell]

Hi,

On Fri, 23 Jun 2017 06:46:53 + <yamada.masah...@socionext.com> wrote:
>
> > -Original Message-
> > From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> > Sent: Friday, June 23, 2017 3:43 PM
> > To: David Miller <da...@davemloft.net>
> > Cc: npig...@gmail.com; linux-n...@vger.kernel.org;
> > linux-kernel@vger.kernel.org; Yamada, Masahiro/山田 真弘
> > <yamada.masah...@socionext.com>; 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 <da...@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

Re: linux-next: build failure after merge of most trees

[Stephen Rothwell]

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

[yamada.masahiro]

Hi Stephen,


> -Original Message-
> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> Sent: Friday, June 23, 2017 3:43 PM
> To: David Miller <da...@davemloft.net>
> Cc: npig...@gmail.com; linux-n...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Yamada, Masahiro/山田 真弘
> <yamada.masah...@socionext.com>; 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 <da...@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.

RE: linux-next: build failure after merge of most trees

[yamada.masahiro]

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

[Stephen Rothwell]

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

[Stephen Rothwell]

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

[Nicholas Piggin]

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

[Nicholas Piggin]

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

[Nicholas Piggin]

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

[Nicholas Piggin]

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

[David Miller]

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

[David Miller]

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

[Nicholas Piggin]

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

[Nicholas Piggin]

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

[Nicholas Piggin]

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

[Nicholas Piggin]

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

[David Miller]

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

[David Miller]

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

[Alan Modra]

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

[Alan Modra]

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

[David Miller]

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

[David Miller]

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

[Nicholas Piggin]

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

[Nicholas Piggin]

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

[Stephen Rothwell]

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=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

[Stephen Rothwell]

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=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

[Stephen Rothwell]

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=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

[Stephen Rothwell]

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=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

[Nicholas Piggin]

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=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

Re: linux-next: build failure after merge of most trees

[Nicholas Piggin]

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=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