From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755302AbdLTNAu (ORCPT ); Wed, 20 Dec 2017 08:00:50 -0500 Received: from mout.kundenserver.de ([212.227.126.133]:56856 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755285AbdLTNAp (ORCPT ); Wed, 20 Dec 2017 08:00:45 -0500 From: Arnd Bergmann To: Linus Walleij Cc: Arnd Bergmann , Russell King , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with future gcc Date: Wed, 20 Dec 2017 14:00:05 +0100 Message-Id: <20171220130016.3156090-1-arnd@arndb.de> X-Mailer: git-send-email 2.9.0 X-Provags-ID: V03:K0:Rzs4YhxQUAFUshI7cC/q75mgy54+oc/LqUtSCILeteBSqBch3u+ HrwMAEhgxBiLPzYBP0j5miepEp6uzJjhKDedOZbJ4iQtzdbX0HAqlF48vbYyQnA2RZrotpf WBCU4XwTYXZ5AuIFMlZBOkyhfTtadN8vcYrBGfWJuctQWy/lroe9OL2FzTqeQavA4ff5Wb7 eWb58lfxKxfm1dJNJ6GfQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:24YuK6l3Gpo=:J1FIzyymOukgP6UvZwdyCA 2L6OJxBoZykym0IBUYsYUL8rFosBuOeADrO8L+ehvCum3KW+3IxkE9qWWs81/4zmfYcKbWYRw rxr+u1jWbNwm2HnvNgvczOE9FTfJeroLBkDixk5wgJt+FNgIaq5XBivdL3GD/UIkP0usnubDX czPmAoZSuqZKra4/RzkcnHklV/Z46NOFvuvUCf4YYVPUrkM3lb63lnO8eF8MdRlr9X/jxfGes 8J/oN7bJqN6sAfinv33kY9OnT9aKgO/GHfhmvUNgSJCOMtAvtSBjGDndRoPNsJrPuNRA1eOU0 I8PlGi2Xz9V5qHX1b7vjzTqUm1bzhSXahWs1j3Pu1LiwZ61bQ681vhqgpsLljIu6sY0bFiwxy q/ey8s9i1kkK1VBJunwscvZD/D1YzNrKATQ78MgiW0F9qjhnCEwvq2Tkvit6qPU0XhEna2Ie0 itICc9ibnySlkhURjhHNJX2MYYScOYtihHeUduRxUeUpLunAUH7k/bTWass2PPjauyvOU0Zwy u9BrwpGWbHcVNOUWrrvZ1Jqyw0romDw3o86OvmCHdInSGgDgVo9sdakOPydMpoz8tU0BAhy6/ xx8oeIdHliydc2A2NhImKjSgQLOKwrI+HDZ2K7KmkxPIEiZBPjzXUfLrw6PNGG7K8QchUy73V OdfJD7T9xHpo8iukX2ShG9h1Zq7M9KTPnZSKJCXjuT1ueUD0u6p4TTttEw2CWGCSNdh9Bcb2/ hNYPA8CDXGWGcaEHsOK48vWVzovSlhOkh0W/kA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 --- 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