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

Open Source and information security mailing list archives

Message-ID: <CAKv+Gu_viATGXTQjywxv8Yyy2iP-nBnAJZBmtnfhsQvS-ueWUA@mail.gmail.com>
Date:   Wed, 20 Dec 2017 13:46:33 +0000
From:   Ard Biesheuvel <ard.biesheuvel@...aro.org>
To:     Arnd Bergmann <arnd@...db.de>
Cc:     Linus Walleij <linus.walleij@...aro.org>,
        linux-arm-kernel@...ts.infradead.org,
        Russell King <linux@...linux.org.uk>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH, RFT] ARM: use --fix-v4bx to allow building ARMv4 with
 future gcc

Hi Arnd,

On 20 December 2017 at 13:00, Arnd Bergmann <arnd@...db.de> wrote:
> 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.
>

Are you sure --fix-v4bx is taken into account during a partial link?

> Signed-off-by: Arnd Bergmann <arnd@...db.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

Shouldn't these two be updated as well?

>  tune-$(CONFIG_CPU_FEROCEON)    =$(call cc-option,-mtune=marvell-f,-mtune=xscale)
> --
> 2.9.0
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives