From: Nicholas Piggin <npiggin@gmail•com>
To: David Miller <davem@davemloft•net>
Cc: sfr@canb•auug.org.au, linux-next@vger•kernel.org,
linux-kernel@vger•kernel.org, yamada.masahiro@socionext•com,
amodra@gmail•com
Subject: Re: linux-next: build failure after merge of most trees
Date: Fri, 23 Jun 2017 13:40:49 +1000 [thread overview]
Message-ID: <20170623134049.72cd0d95@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <20170622.102923.1704137848607888832.davem@davemloft.net>
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
next prev parent reply other threads:[~2017-06-23 3: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
2017-06-22 14:13 ` David Miller
2017-06-22 14:29 ` David Miller
2017-06-23 3:40 ` Nicholas Piggin [this message]
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=20170623134049.72cd0d95@roar.ozlabs.ibm.com \
--to=npiggin@gmail$(echo .)com \
--cc=amodra@gmail$(echo .)com \
--cc=davem@davemloft$(echo .)net \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=yamada.masahiro@socionext$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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