From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: move __fixup_smp out of init section
Date: Tue, 25 Feb 2014 19:32:13 +0100 [thread overview]
Message-ID: <22591791.dKqiiVNNOv@wuerfel> (raw)
In-Reply-To: <1393352193-31717-1-git-send-email-robherring2@gmail.com>
On Tuesday 25 February 2014 12:16:33 Rob Herring wrote:
> From: Rob Herring <robh@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@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?
* 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
* 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?
* 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.
The complete patch I have is at http://pastebin.com/5yVaUC4u, but it's
likely that it's completely broken ;-)
Arnd
next prev parent reply other threads:[~2014-02-25 18:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-25 18:16 [PATCH] ARM: move __fixup_smp out of init section Rob Herring
2014-02-25 18:32 ` Arnd Bergmann [this message]
2014-02-25 21:05 ` Rob Herring
2014-02-25 21:10 ` Arnd Bergmann
2014-02-25 21:46 ` Rob Herring
2014-02-25 21:56 ` Arnd Bergmann
2014-02-26 12:24 ` Russell King - ARM Linux
2014-02-26 20:56 ` Rob Herring
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=22591791.dKqiiVNNOv@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/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