From: Helge Deller <deller@gmx.de>
To: "Maciej W. Rozycki" <macro@linux-mips.org>,
Bob Tracy <rct@gherkin.frus.com>
Cc: Matt Turner <mattst88@gmail.com>,
linux-alpha <linux-alpha@vger.kernel.org>,
Debian Alpha Mailing List <debian-alpha@lists.debian.org>,
Michael Cree <mcree@orcon.net.nz>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [BUG] 4.9.0 build error on Alpha
Date: Fri, 30 Dec 2016 22:07:06 +0100 [thread overview]
Message-ID: <3a3389e5-e6f5-5ec3-ca26-762162d2a4ac@gmx.de> (raw)
In-Reply-To: <alpine.LFD.2.20.1612301554130.1811@eddie.linux-mips.org>
[-- Attachment #1: Type: text/plain, Size: 1326 bytes --]
Hi Bob,
On 30.12.2016 17:02, Maciej W. Rozycki wrote:
> On Thu, 29 Dec 2016, Bob Tracy wrote:
>
>>> I'm guessing it's another symptom of the old "kernel too big" problem?
>>
>> How has this been worked around in the past? I have a fairly
>> feature-full kernel, but the only built-in drivers are for the things
>> that have to be present at boot time.
>
> This looks like a link ordering issue to me, the failures are branches
> between objects built from arch/alpha/lib/*.S assembly sources, which
> must have got moved apart more with the switch of the compiler version.
Seems right.
> One workaround might be making them a .o rather than .a target, which
> will ensure they're close to each other, at the cost of a small kernel
> size increase if some of these functions would otherwise be unused.
Possible.
> Replacing branches with full address calculation and register jumps might
> be another, although this would cost some run time instead, so I think the
> former approach is a bit better.
Another possibility could be to put all the lib functions into
a "alphalib" section into the final vmlinux.
For that add at the top of each of the .S files in lib/
.section .alphalib,"ax"
and apply the attached patch for arch/alpha/kernel/vmlinux.lds.S
Patch and suggestion is completely untested.
Helge
[-- Attachment #2: p1 --]
[-- Type: text/plain, Size: 369 bytes --]
diff --git a/arch/alpha/kernel/vmlinux.lds.S b/arch/alpha/kernel/vmlinux.lds.S
index cebecfb..88af6bc 100644
--- a/arch/alpha/kernel/vmlinux.lds.S
+++ b/arch/alpha/kernel/vmlinux.lds.S
@@ -20,6 +20,9 @@ SECTIONS
_text = .; /* Text and read-only data */
.text : {
HEAD_TEXT
+ .alphalib: {
+ *(.alphalib)
+ } :kernel
TEXT_TEXT
SCHED_TEXT
CPUIDLE_TEXT
next prev parent reply other threads:[~2016-12-30 21:07 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-30 3:08 [BUG] 4.9.0 build error on Alpha Bob Tracy
2016-12-30 3:23 ` Matt Turner
2016-12-30 3:37 ` Bob Tracy
2016-12-30 16:02 ` Maciej W. Rozycki
2016-12-30 21:07 ` Helge Deller [this message]
2016-12-31 6:43 ` Bob Tracy
2016-12-31 7:20 ` Bob Tracy
2016-12-31 10:11 ` Maciej W. Rozycki
2016-12-31 15:20 ` Bob Tracy
2016-12-31 19:38 ` Michael Cree
2016-12-31 21:09 ` Bob Tracy
2017-01-01 1:23 ` Maciej W. Rozycki
2017-01-01 3:32 ` Bob Tracy
2017-01-01 20:29 ` Bob Tracy
2017-01-03 0:15 ` Bob Tracy
2017-01-12 12:52 ` Maciej W. Rozycki
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=3a3389e5-e6f5-5ec3-ca26-762162d2a4ac@gmx.de \
--to=deller@gmx.de \
--cc=debian-alpha@lists.debian.org \
--cc=linux-alpha@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=mattst88@gmail.com \
--cc=mcree@orcon.net.nz \
--cc=rct@gherkin.frus.com \
--cc=rth@twiddle.net \
/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 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.