[PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc

[Arnd Bergmann]

gcc-6.0 and later marks support for ARMv3 and ARMv4 as 'deprecated',
meaning that this is expected to be removed at some point in the future,
with gcc-8.0 as the earliest.

When building the kernel, the difference between ARMv4 and ARMv4T
is relatively small because the kernel never runs THUMB instructions
on ARMv4T and does not need any support for interworking.

For any future compiler that does not support -march=armv4, we now
fall back to -march=armv4t as the architecture level selection,
but keep using -march=armv4 by default as long as that is supported
by the compiler.

Similarly, the -mtune=strongarm110 and -mtune=strongarm1100 options
will go away at the same time as -march=armv4, so this adds a check
to see if the compiler supports them, falling back to no -mtune
option otherwise.

Compiling with -march=armv4t leads the compiler to using 'bx reg'
instructions instead of 'mov pc,reg'. This is not supported on
ARMv4 based CPUs, but the linker can work around this by rewriting
those instructions to the ARMv4 version if we pass --fix-v4bx
to the linker. This should work with binutils-2.15 (released
May 2004) or higher, and we can probably assume that anyone using
gcc-7.x will have a much more recent binutils version as well.

However, in order to still allow users of old toolchains to link
the kernel, we only pass the option to linkers that support it,
based on a $(ld-option ...) call. I'm intentionally passing the
flag to all linker versions here regardless of whether it's needed
or not, so we can more easily spot any regressions if something
goes wrong.

For consistency, I'm passing the --fix-v4bx flag for both the
vmlinux final link and the individual loadable modules.
The module loader code already interprets the R_ARM_V4BX relocations
in loadable modules and converts bx instructions into mov even
when running on ARMv4T or ARMv5 processors. This is now redundant
when we pass --fix-v4bx to the linker for building modules, but
I see no harm in leaving the current implementation and doing both.

Signed-off-by: Arnd Bergmann <arnd at arndb.de>
---
Please test by making the -march=armv4t switch unconditional
and see if that results in a working kernel

 arch/arm/Makefile | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/arm/Makefile b/arch/arm/Makefile
index e83f5161fdd8..33b7eb4502aa 100644
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@ -19,6 +19,11 @@ LDFLAGS_vmlinux	+= --be8
 KBUILD_LDFLAGS_MODULE	+= --be8
 endif
 
+ifeq ($(CONFIG_CPU_32v4),y)
+LDFLAGS_vmlinux	+= $(call ld-option,--fix-v4bx)
+LDFLAGS_MODULE	+= $(call ld-option,--fix-v4bx)
+endif
+
 ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
 KBUILD_LDFLAGS_MODULE	+= -T $(srctree)/arch/arm/kernel/module.lds
 endif
@@ -76,7 +81,7 @@ arch-$(CONFIG_CPU_32v6K)	=-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,
 endif
 arch-$(CONFIG_CPU_32v5)		=-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4t)
 arch-$(CONFIG_CPU_32v4T)	=-D__LINUX_ARM_ARCH__=4 -march=armv4t
-arch-$(CONFIG_CPU_32v4)		=-D__LINUX_ARM_ARCH__=4 -march=armv4
+arch-$(CONFIG_CPU_32v4)		=-D__LINUX_ARM_ARCH__=4 $(call cc-option,-march=armv4,-march=armv4t)
 arch-$(CONFIG_CPU_32v3)		=-D__LINUX_ARM_ARCH__=3 -march=armv3
 
 # Evaluate arch cc-option calls now
@@ -94,8 +99,8 @@ tune-$(CONFIG_CPU_ARM922T)	=-mtune=arm9tdmi
 tune-$(CONFIG_CPU_ARM925T)	=-mtune=arm9tdmi
 tune-$(CONFIG_CPU_ARM926T)	=-mtune=arm9tdmi
 tune-$(CONFIG_CPU_FA526)	=-mtune=arm9tdmi
-tune-$(CONFIG_CPU_SA110)	=-mtune=strongarm110
-tune-$(CONFIG_CPU_SA1100)	=-mtune=strongarm1100
+tune-$(CONFIG_CPU_SA110)	=$(call cc-option,-mtune=strongarm110)
+tune-$(CONFIG_CPU_SA1100)	=$(call cc-option,-mtune=strongarm1100)
 tune-$(CONFIG_CPU_XSCALE)	=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
 tune-$(CONFIG_CPU_XSC3)		=$(call cc-option,-mtune=xscale,-mtune=strongarm110) -Wa,-mcpu=xscale
 tune-$(CONFIG_CPU_FEROCEON)	=$(call cc-option,-mtune=marvell-f,-mtune=xscale)
-- 
2.9.0