@@ -19,6 +19,11 @@ LDFLAGS_vmlinux += --be8
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)
LDFLAGS_MODULE += -T $(srctree)/arch/arm/kernel/module.lds
endif
@@ -75,7 +80,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
@@ -93,8 +98,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)
gcc-6.0 marks support for ARMv3 and ARMv4 as 'deprecated', meaning that this is expected to be removed at some point in the future, with gcc-7.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 'ld 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 ldr 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@arndb.de> _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel