From: linux@armlinux.org.uk (Russell King - ARM Linux)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 0/8] ARM: clean up PC-relative arithmetic
Date: Thu, 4 Aug 2016 10:49:40 +0100 [thread overview]
Message-ID: <20160804094940.GM1041@n2100.armlinux.org.uk> (raw)
In-Reply-To: <CAKv+Gu-+ib-XuQfg8ZL4D7nSk5YRSYaCQyf+UdZPmg+5CxPmJw@mail.gmail.com>
On Thu, Aug 04, 2016 at 09:17:04AM +0200, Ard Biesheuvel wrote:
> On 3 August 2016 at 20:17, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > I don't buy that argument, sorry, and the argument is actually wrong.
> > No, we're _not_ letting the linker do the calculations for us, we're
> > letting the linker do _some_ of the calculation, but not all.
> >
> > What you're replacing the above with is stuff like (I guess, because
> > I've no idea what this :pc_g0: notation is):
> >
> > add rX, pc, #(sym - . - 8) & 0xff
> > add rX, rX, #(sym - . - 4) & 0xff00
> > add rX, rX, #(sym - .) & 0xff0000
> >
> > which I think is a more complex (and less obvious) way to calculate it.
> > It's also buggy when we end up with a relative offset greater than 16MB,
> > which we have in multi-zImage kernels.
> >
>
> Even if you think this is a more complex way to calculate it, at least
> it is encapsulated in a single macro instead of having similar but not
> identical open coded instances all over the place.
... and, it may come as a shocker, but I don't have a problem with
that.
> As for the range: the ldr/str variants have 28 bits of range (2x
> scaled 8 bit immediate for the adds and a single unscaled 12 bit
> immediate for the ldr/str). The adr variant has 26 bits (3x scaled
> immediate counting from bit 2) range for word aligned symbols, which
> gives us +/- 64 MB, which should be plenty. The only pathological
> outlier is allyesconfig, but that uses Thumb2 anyway.
Our existing code allows for a range of the full address space - the only
thing it relies upon is that the literal data is placed within reach of
the code - which it will be, because it's always placed near the code
which is using it.
> The relocations documented here
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0044f/IHI0044F_aaelf.pdf
Right, so it's an EABI thing, and I guess you haven't tested OABI
builds, where I suspect these relocations aren't supported.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
next prev parent reply other threads:[~2016-08-04 9:49 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-03 15:38 [PATCH 0/8] ARM: clean up PC-relative arithmetic Ard Biesheuvel
2016-08-03 15:38 ` [PATCH 1/8] ARM: assembler: introduce adr_l, ldr_l and str_l macros Ard Biesheuvel
2016-08-03 16:49 ` Dave Martin
2016-08-04 7:40 ` Ard Biesheuvel
2016-08-04 9:44 ` Dave Martin
2016-08-04 10:34 ` Ard Biesheuvel
2016-08-04 11:22 ` Dave Martin
2016-08-04 12:16 ` Russell King - ARM Linux
2016-08-04 12:55 ` Dave Martin
2016-08-04 13:58 ` Ard Biesheuvel
2016-08-04 7:43 ` Ard Biesheuvel
2016-08-03 18:09 ` Russell King - ARM Linux
2016-08-04 7:40 ` Ard Biesheuvel
2016-08-04 9:38 ` Dave Martin
2016-08-04 10:12 ` Ard Biesheuvel
2016-08-04 11:08 ` Dave Martin
2016-08-04 11:10 ` Ard Biesheuvel
2016-08-04 11:30 ` Dave Martin
2016-08-04 11:34 ` Ard Biesheuvel
2016-08-04 13:31 ` Dave Martin
2016-08-04 13:46 ` Ard Biesheuvel
2016-08-04 15:38 ` Dave Martin
2016-08-03 15:38 ` [PATCH 2/8] ARM: head-common.S: use PC-relative insn sequence for __proc_info Ard Biesheuvel
2016-08-03 15:38 ` [PATCH 3/8] ARM: head-common.S: use PC-relative insn sequence for __turn_mmu_on Ard Biesheuvel
2016-08-03 15:38 ` [PATCH 4/8] ARM: head.S: use PC-relative insn sequence for secondary_data Ard Biesheuvel
2016-08-03 18:06 ` Russell King - ARM Linux
2016-08-03 15:38 ` [PATCH 5/8] ARM: head: use PC-relative insn sequence for __smp_alt Ard Biesheuvel
2016-08-03 15:38 ` [PATCH 6/8] ARM: sleep.S: use PC-relative insn sequence for sleep_save_sp/mpidr_hash Ard Biesheuvel
2016-08-03 15:38 ` [PATCH 7/8] ARM: head.S: use PC-relative insn sequences for __fixup_pv_table Ard Biesheuvel
2016-08-03 15:38 ` [PATCH 8/8] ARM: head.S: use PC relative insn sequence to calculate PHYS_OFFSET Ard Biesheuvel
2016-08-03 18:17 ` [PATCH 0/8] ARM: clean up PC-relative arithmetic Russell King - ARM Linux
2016-08-04 7:17 ` Ard Biesheuvel
2016-08-04 9:49 ` Russell King - ARM Linux [this message]
2016-08-04 9:54 ` Ard Biesheuvel
2016-08-04 10:03 ` Russell King - ARM Linux
2016-08-04 10:11 ` Ard Biesheuvel
2016-08-04 10:14 ` Russell King - ARM Linux
2016-08-03 18:27 ` Nicolas Pitre
2016-08-04 14:11 ` Ard Biesheuvel
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=20160804094940.GM1041@n2100.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--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 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.