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