[PATCH] ARM: move __fixup_smp out of init section

[Rob Herring]

On Tue, Feb 25, 2014 at 12:32 PM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Tuesday 25 February 2014 12:16:33 Rob Herring wrote:
>> From: Rob Herring <robh at kernel.org>
>>
>> With large kernel builds such as allyesconfig exceeding maximum relative
>> branch offsets, the init section will be too far away to branch to
>> directly. This causes veneers to be added by the compiler, but veneers
>> don't work before the MMU is enabled. Fix this by moving __fixup_smp to
>> the .head.text section as it is not very big.
>>
>> Signed-off-by: Rob Herring <robh at kernel.org>
>
> This looks good to me, but I have some related questions:
>
> * I needed to use -mlong-calls for large kernels. Did you manage without?

Yes, but I started with allyesconfig and then disabled things until it
would link. This was mainly PCI, various debug, and filesystems. This
particular failure you don't see until you try to boot.

I also saw intermittent inconsistent kallsym errors which
KALLSYMS_EXTRA_PASS=1 did not fix.

> * Do you (or anyone) know how to force the use of a veneer? I see a problem
>   with some driver calling __do_div_asm from IIRC an init section, and that
>   creates a link error when the kernel gets too big

That is surprising given that I saw veneers be inserted for some asm
to asm calls. Maybe it is something I turned off or something to do
with the types of sections.

> * If FUNCTION_TRACER is enabled, we get calls from every function using
>  'bl __gnu_mcount_nc'. Do you think it's possible to fix those?

Put it in the middle of the image? ;)

> * Same thing but simpler for svc_preempt calling preempt_schedule_irq
>   and lookup_processor_type calling __lookup_processor_type. In those
>   cases I guess we should be able to trivially rewrite the assembly
>   to jump through an extra register.

I did see that lookup_processor_type had a veneer in my build.

Rob