From: nico@fluxnic.net (Nicolas Pitre)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] arm: decompressor: initialize PIC offset base register for uClinux tools
Date: Tue, 29 Jan 2013 15:13:36 -0500 (EST) [thread overview]
Message-ID: <alpine.LFD.2.02.1301291453530.6300@xanadu.home> (raw)
In-Reply-To: <1359480546-7033-1-git-send-email-jonathan.austin@arm.com>
On Tue, 29 Jan 2013, Jonathan Austin wrote:
> Before jumping to (position independent) C-code from the decompressor's
> assembler world we set-up the C environment. This setup currently does not
> set r9, which for arm-none-uclinux-uclibceabi should be the PIC offset base
> register (IE should point to the beginning of the GOT).
>
> Currently, therefore, in order to build working kernels that use the
> decompressor it is necessary to use an arm-linux-gnueabi toolchain, or
> similar. uClinux toolchains cause a Prefetch Abort to occur at the beginning
> of the decompress_kernel function.
>
> This patch allows uClinux toolchains to build bootable zImages by setting r9
> to the beginning of the GOT when __uClinux__ is defined, allowing the
> decompressor's C functions to work correctly.
>
> Signed-off-by: Jonathan Austin <jonathan.austin@arm.com>
> ---
>
> One other possibility would be to specify -mno-single-pic-base when building
> the decompressor. This works around the problem, but forces the compiler to
> generate less optimal code.
How "less optimal"? How much bigger/slower is it?
If not significant enough then going with -mno-single-pic-base might be
fine.
> arch/arm/boot/compressed/head.S | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/arch/arm/boot/compressed/head.S b/arch/arm/boot/compressed/head.S
> index fe4d9c3..4491e75 100644
> --- a/arch/arm/boot/compressed/head.S
> +++ b/arch/arm/boot/compressed/head.S
> @@ -410,6 +410,10 @@ wont_overwrite:
> * sp = stack pointer
> */
> orrs r1, r0, r5
> +#ifdef __uClinux__
> + mov r9, r11 @ PIC offset base register
> + addne r9, r9, r0 @ Also needs relocating
> +#endif
> beq not_relocated
Please don't insert your code between the orrs and the beq as those two
go logically together.
In fact, the best location for this would probably be between the
wont_overwrite label and the comment that immediately follows it. And
then, those comments that follow until the branch into C code should be
updated accordingly.
Nicolas
next prev parent reply other threads:[~2013-01-29 20:13 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-29 17:29 [RFC PATCH] arm: decompressor: initialize PIC offset base register for uClinux tools Jonathan Austin
2013-01-29 20:13 ` Nicolas Pitre [this message]
2013-02-01 16:43 ` Jonathan Austin
2013-02-01 18:07 ` Nicolas Pitre
2013-02-01 18:18 ` Russell King - ARM Linux
2013-02-04 12:00 ` Jonathan Austin
2013-02-04 12:07 ` Russell King - ARM Linux
2013-02-04 12:20 ` Jonathan Austin
2013-02-04 12:23 ` Russell King - ARM Linux
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=alpine.LFD.2.02.1301291453530.6300@xanadu.home \
--to=nico@fluxnic.net \
--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;
as well as URLs for NNTP newsgroup(s).