From: Arnd Bergmann arnd@arndb.de
Naresh and Antonio ran into a build failure with latest Debian armhf compilers, with lots of output like
tmp/ccY3nOAs.s:2215: Error: selected processor does not support `cpsid i' in ARM mode
As it turns out, $(cc-option) fails early here when the FPU is not selected before CPU architecture is selected, as the compiler option check runs before enabling -msoft-float, which causes a problem when testing a target architecture level without an FPU:
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
Passing e.g. -march=armv6k+fp in place of -march=armv6k would avoid this issue, but the fallback logic is already broken because all supported compilers (gcc-5 and higher) are much more recent than these options, and building with -march=armv5t as a fallback no longer works.
The best way forward that I see is to just remove all the checks, which also has the nice side-effect of slightly improving the startup time for 'make'.
The -mtune=marvell-f option was apparently never supported by any mainline compiler, and the custom Codesourcery gcc build that did support is now too old to build kernels, so just use -mtune=xscale unconditionally for those.
This should be safe to apply on all stable kernels, and will be required in order to keep building them with gcc-11 and higher.
Reported-by: Antonio Terceiro antonio.terceiro@linaro.org Reported-by: Naresh Kamboju naresh.kamboju@linaro.org Reported-by: Sebastian Andrzej Siewior sebastian@breakpoint.cc Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996419 Cc: Matthias Klose doko@debian.org Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann arnd@arndb.de --- arch/arm/Makefile | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 847c31e7c368..fa45837b8065 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -60,15 +60,15 @@ KBUILD_CFLAGS += $(call cc-option,-fno-ipa-sra) # Note that GCC does not numerically define an architecture version # macro, but instead defines a whole series of macros which makes # testing for a specific architecture or later rather impossible. -arch-$(CONFIG_CPU_32v7M) =-D__LINUX_ARM_ARCH__=7 -march=armv7-m -Wa,-march=armv7-m -arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a) -arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6) +arch-$(CONFIG_CPU_32v7M) =-D__LINUX_ARM_ARCH__=7 -march=armv7-m +arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 -march=armv7-a +arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 -march=armv6 # Only override the compiler option if ARMv6. The ARMv6K extensions are # always available in ARMv7 ifeq ($(CONFIG_CPU_32v6),y) -arch-$(CONFIG_CPU_32v6K) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,-march=armv5t -Wa$(comma)-march=armv6k) +arch-$(CONFIG_CPU_32v6K) =-D__LINUX_ARM_ARCH__=6 -march=armv6k endif -arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4t) +arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 -march=armv5te 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_32v3) =-D__LINUX_ARM_ARCH__=3 -march=armv3m @@ -82,7 +82,7 @@ tune-$(CONFIG_CPU_ARM720T) =-mtune=arm7tdmi tune-$(CONFIG_CPU_ARM740T) =-mtune=arm7tdmi tune-$(CONFIG_CPU_ARM9TDMI) =-mtune=arm9tdmi tune-$(CONFIG_CPU_ARM940T) =-mtune=arm9tdmi -tune-$(CONFIG_CPU_ARM946E) =$(call cc-option,-mtune=arm9e,-mtune=arm9tdmi) +tune-$(CONFIG_CPU_ARM946E) =-mtune=arm9e tune-$(CONFIG_CPU_ARM920T) =-mtune=arm9tdmi tune-$(CONFIG_CPU_ARM922T) =-mtune=arm9tdmi tune-$(CONFIG_CPU_ARM925T) =-mtune=arm9tdmi @@ -90,11 +90,11 @@ 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_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) -tune-$(CONFIG_CPU_V6) =$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm) -tune-$(CONFIG_CPU_V6K) =$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm) +tune-$(CONFIG_CPU_XSCALE) =-mtune=xscale +tune-$(CONFIG_CPU_XSC3) =-mtune=xscale +tune-$(CONFIG_CPU_FEROCEON) =-mtune=xscale +tune-$(CONFIG_CPU_V6) =-mtune=arm1136j-s +tune-$(CONFIG_CPU_V6K) =-mtune=arm1136j-s
# Evaluate tune cc-option calls now tune-y := $(tune-y)
On 2021-10-18 16:07:12 [+0200], Arnd Bergmann wrote: …
Passing e.g. -march=armv6k+fp in place of -march=armv6k would avoid this issue, but the fallback logic is already broken because all supported compilers (gcc-5 and higher) are much more recent than these options, and building with -march=armv5t as a fallback no longer works.
The best way forward that I see is to just remove all the checks, which also has the nice side-effect of slightly improving the startup time for 'make'.
…
This should be safe to apply on all stable kernels, and will be required in order to keep building them with gcc-11 and higher.
Yes, please.
Reported-by: Antonio Terceiro antonio.terceiro@linaro.org Reported-by: Naresh Kamboju naresh.kamboju@linaro.org Reported-by: Sebastian Andrzej Siewior sebastian@breakpoint.cc Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996419 Cc: Matthias Klose doko@debian.org Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann arnd@arndb.de
Reviewed-by: Sebastian Andrzej Siewior sebastian@breakpoint.cc
Just booted Debian 9/ Stretch which ships gcc version 6.3.0 20170516 (Debian 6.3.0-18)
to confirm that it fails to compile with the armv5t fallback.
Sebastian
On 18.10.21 16:07, Arnd Bergmann wrote:
From: Arnd Bergmann arnd@arndb.de
Naresh and Antonio ran into a build failure with latest Debian armhf compilers, with lots of output like
tmp/ccY3nOAs.s:2215: Error: selected processor does not support `cpsid i' in ARM mode
I just had exactly the same problem, and this patch fixes it for me as well. Compile- and run-tested with gcc-11 (Debian 11.2.0-10) armhf & Linux 5.15.0
Tested-by: Klaus Kudielka klaus.kudielka@gmail.com
On 2021-10-18 16:07:12 [+0200], Arnd Bergmann wrote: …
This should be safe to apply on all stable kernels, and will be required in order to keep building them with gcc-11 and higher.
Could we get this applied, please?
Matthias Klose asked gcc-upstream if the change, causing the problem, was expected/ intended. I don't think this matters given that the provided fallback does not work.
Sebastian
Hi,
On Mon, Oct 18, 2021 at 04:07:12PM +0200, Arnd Bergmann wrote:
From: Arnd Bergmann arnd@arndb.de
Naresh and Antonio ran into a build failure with latest Debian armhf compilers, with lots of output like
tmp/ccY3nOAs.s:2215: Error: selected processor does not support `cpsid i' in ARM mode
As it turns out, $(cc-option) fails early here when the FPU is not selected before CPU architecture is selected, as the compiler option check runs before enabling -msoft-float, which causes a problem when testing a target architecture level without an FPU:
cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
Passing e.g. -march=armv6k+fp in place of -march=armv6k would avoid this issue, but the fallback logic is already broken because all supported compilers (gcc-5 and higher) are much more recent than these options, and building with -march=armv5t as a fallback no longer works.
The best way forward that I see is to just remove all the checks, which also has the nice side-effect of slightly improving the startup time for 'make'.
The -mtune=marvell-f option was apparently never supported by any mainline compiler, and the custom Codesourcery gcc build that did support is now too old to build kernels, so just use -mtune=xscale unconditionally for those.
This should be safe to apply on all stable kernels, and will be required in order to keep building them with gcc-11 and higher.
Reported-by: Antonio Terceiro antonio.terceiro@linaro.org Reported-by: Naresh Kamboju naresh.kamboju@linaro.org Reported-by: Sebastian Andrzej Siewior sebastian@breakpoint.cc Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=996419 Cc: Matthias Klose doko@debian.org Cc: stable@vger.kernel.org Signed-off-by: Arnd Bergmann arnd@arndb.de
Thanks, I ran into this issue after affected gcc release migrated to Debian testing. The patch makes the kernel compile again:
Tested-by: Sebastian Reichel sebastian.reichel@collabora.com
Would be great if this could become part of 5.16-rc1, which is usually used as base by subsystem maintainers.
Thanks,
-- Sebastian
arch/arm/Makefile | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/arch/arm/Makefile b/arch/arm/Makefile index 847c31e7c368..fa45837b8065 100644 --- a/arch/arm/Makefile +++ b/arch/arm/Makefile @@ -60,15 +60,15 @@ KBUILD_CFLAGS += $(call cc-option,-fno-ipa-sra) # Note that GCC does not numerically define an architecture version # macro, but instead defines a whole series of macros which makes # testing for a specific architecture or later rather impossible. -arch-$(CONFIG_CPU_32v7M) =-D__LINUX_ARM_ARCH__=7 -march=armv7-m -Wa,-march=armv7-m -arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 $(call cc-option,-march=armv7-a,-march=armv5t -Wa$(comma)-march=armv7-a) -arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6,-march=armv5t -Wa$(comma)-march=armv6) +arch-$(CONFIG_CPU_32v7M) =-D__LINUX_ARM_ARCH__=7 -march=armv7-m +arch-$(CONFIG_CPU_32v7) =-D__LINUX_ARM_ARCH__=7 -march=armv7-a +arch-$(CONFIG_CPU_32v6) =-D__LINUX_ARM_ARCH__=6 -march=armv6 # Only override the compiler option if ARMv6. The ARMv6K extensions are # always available in ARMv7 ifeq ($(CONFIG_CPU_32v6),y) -arch-$(CONFIG_CPU_32v6K) =-D__LINUX_ARM_ARCH__=6 $(call cc-option,-march=armv6k,-march=armv5t -Wa$(comma)-march=armv6k) +arch-$(CONFIG_CPU_32v6K) =-D__LINUX_ARM_ARCH__=6 -march=armv6k endif -arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 $(call cc-option,-march=armv5te,-march=armv4t) +arch-$(CONFIG_CPU_32v5) =-D__LINUX_ARM_ARCH__=5 -march=armv5te 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_32v3) =-D__LINUX_ARM_ARCH__=3 -march=armv3m @@ -82,7 +82,7 @@ tune-$(CONFIG_CPU_ARM720T) =-mtune=arm7tdmi tune-$(CONFIG_CPU_ARM740T) =-mtune=arm7tdmi tune-$(CONFIG_CPU_ARM9TDMI) =-mtune=arm9tdmi tune-$(CONFIG_CPU_ARM940T) =-mtune=arm9tdmi -tune-$(CONFIG_CPU_ARM946E) =$(call cc-option,-mtune=arm9e,-mtune=arm9tdmi) +tune-$(CONFIG_CPU_ARM946E) =-mtune=arm9e tune-$(CONFIG_CPU_ARM920T) =-mtune=arm9tdmi tune-$(CONFIG_CPU_ARM922T) =-mtune=arm9tdmi tune-$(CONFIG_CPU_ARM925T) =-mtune=arm9tdmi @@ -90,11 +90,11 @@ 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_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) -tune-$(CONFIG_CPU_V6) =$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm) -tune-$(CONFIG_CPU_V6K) =$(call cc-option,-mtune=arm1136j-s,-mtune=strongarm) +tune-$(CONFIG_CPU_XSCALE) =-mtune=xscale +tune-$(CONFIG_CPU_XSC3) =-mtune=xscale +tune-$(CONFIG_CPU_FEROCEON) =-mtune=xscale +tune-$(CONFIG_CPU_V6) =-mtune=arm1136j-s +tune-$(CONFIG_CPU_V6K) =-mtune=arm1136j-s # Evaluate tune cc-option calls now tune-y := $(tune-y) -- 2.29.2
On Sat, Nov 6, 2021 at 5:59 PM Sebastian Reichel sebastian.reichel@collabora.com wrote:
Thanks, I ran into this issue after affected gcc release migrated to Debian testing. The patch makes the kernel compile again:
Tested-by: Sebastian Reichel sebastian.reichel@collabora.com
Would be great if this could become part of 5.16-rc1, which is usually used as base by subsystem maintainers.
I've added it to Russell's patch tracker now as
https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9156/1
Arnd
Hi,
On Sat, Nov 06, 2021 at 08:04:35PM +0100, Arnd Bergmann wrote:
On Sat, Nov 6, 2021 at 5:59 PM Sebastian Reichel sebastian.reichel@collabora.com wrote:
Thanks, I ran into this issue after affected gcc release migrated to Debian testing. The patch makes the kernel compile again:
Tested-by: Sebastian Reichel sebastian.reichel@collabora.com
Would be great if this could become part of 5.16-rc1, which is usually used as base by subsystem maintainers.
I've added it to Russell's patch tracker now as
https://www.armlinux.org.uk/developer/patches/viewpatch.php?id=9156/1
Thanks.
FWIW, we uploaded in Debian 5.15.1 to experimental with the patch applied, and the builds pass now: https://buildd.debian.org/status/logs.php?pkg=linux&arch=armhf
Regards, Salvatore
linux-stable-mirror@lists.linaro.org
-
Arnd Bergmann -
Klaus Kudielka -
Salvatore Bonaccorso -
Sebastian Andrzej Siewior -
Sebastian Reichel