Any progress on R_ARM_THM_JUMP11 issues?
rsalvaterra at gmail.com
Thu Jun 18 00:18:07 CEST 2020
Hi again, Jason,
[Adding a bit of extra context for linux-arm-kernel.]
On Wed, 17 Jun 2020 at 22:02, Jason A. Donenfeld <Jason at zx2c4.com> wrote:
> But I am wondering: has anybody heard about toolchain progress toward
> fixing this? Couldn't the compiler reorder functions itself more
> intelligently? Or avoid emitting the B in the case that the jump will
> be too far? Or does nobody care much about 32-bit ARM these days so
> it's just fallen by the wayside and
> CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y is the best we've got? Or
> something else?
The thing is, CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y implies
-fno-optimize-sibling-calls, which seems like a big hammer to work
around a toolchain bug.
Now, this bug has been reported in Linaro binutils as early as
February 2011  and the upstream bug has been deemed fixed in
binutils 2.22 , two months later. I usually don't build modular
kernels, but in OpenWrt we don't have a choice due to the compat
backports of wireless drivers. What strikes me as odd is the fact that
without CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11, all kernel modules load
and run just fine, except for WireGuard. Anyway, I completely agree
that if it's a toolchain bug, the toolchain must be fixed.
Out of curiosity, I also compared the vmlinux sizes in both modes
(OpenWrt kernel, Linux 5.4.46 with my Turris Omnia configuration, gcc
9.3.0 and binutils 2.34).
Thumb-2 (with CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y):
A 2 MiB smaller code footprint is nothing to sneeze at.
More information about the WireGuard