linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: David Miller <davem@davemloft.net>,
	Linux-Next Mailing List <linux-next@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Masahiro Yamada <yamada.masahiro@socionext.com>,
	Alan Modra <amodra@gmail.com>
Subject: Re: linux-next: build failure after merge of most trees
Date: Thu, 22 Jun 2017 18:41:16 +1000	[thread overview]
Message-ID: <20170622184116.0ebaabd9@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <20170622152441.3704b3d9@canb.auug.org.au>

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

  parent reply	other threads:[~2017-06-22  8:41 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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  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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170622184116.0ebaabd9@roar.ozlabs.ibm.com \
    --to=npiggin@gmail.com \
    --cc=amodra@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=yamada.masahiro@socionext.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).