Hi again, Jason, [Adding a bit of extra context for linux-arm-kernel.]
On Wed, 17 Jun 2020 at 22:02, Jason A. Donenfeld <ja...@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 [1] and the upstream bug has been deemed fixed in binutils 2.22 [2], 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). Pure ARM: 24243392 bytes Thumb-2 (with CONFIG_THUMB2_AVOID_R_ARM_THM_JUMP11=y): 22102716 bytes A 2 MiB smaller code footprint is nothing to sneeze at. [1] https://bugs.launchpad.net/binutils-linaro/+bug/725126 [2] https://sourceware.org/bugzilla/show_bug.cgi?id=12532 Cheers, Rui _______________________________________________ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
