From 9a6882502d353b89fd2c82b03d9267c94684e4b2 Mon Sep 17 00:00:00 2001 From: Nathan Chancellor Date: Tue, 20 Oct 2026 14:52:18 -0700 Subject: [PATCH 1/2] kbuild: Move testing of '-mfentry' back to Makefile from Kconfig Unlike cc-option in Kbuild, cc-option in Kconfig does not test options with either bit ('-m32' / '-m64') or endianness ('-mbig-endian' / '-mlittle-endian') flags because which flag to use may depend on the result of the configuration stage. This difference changes the result of testing for '-mfentry' support when using the kernel.org s390 cross compiler, which is configured for 32-bit by default. $ s390-linux-gcc -mfentry -o /dev/null -x c -c /dev/null cc1: error: '-mfentry' is supported only for 64-bit CPUs arch/s390/Makefile sets '-m64' in KBUILD_CPPFLAGS early, so '-mfentry' support was properly tested before the move to Kconfig. $ s390-linux-gcc -m64 -mfentry -o /dev/null -x c -c /dev/null Ricardo reported another issue with moving this check from Kbuild to Kconfig, as '-mfentry' is not supported for x86_32 without '-fno-pic', which affects GCC builds that are configured with PIE enabled by default. arch/x86/Makefile adds '-fno-pic' to KBUILD_CFLAGS, so this works properly in Kbuild. Move the '-mfentry' check back into Kbuild to avoid adding additional complexity to the Kconfig entry. Fixes: 454e00cf8ee5 ("kbuild: avoid re-running compiler and linker probes") Reported-by: Ricardo Ribalda Closes: https://lore.kernel.org/20261020-pie-v1-1-9be09f2324b1@chromium.org/ Link: https://patch.msgid.link/20261020-kconfig-fix-mfentry-check-v1-1-428258bc0fc0@kernel.org Signed-off-by: Nathan Chancellor --- Makefile | 3 ++- scripts/Kconfig.toolchain | 4 ---- 2 files changed, 2 insertions(+), 5 deletions(-) diff --git a/Makefile b/Makefile index 8d23af898d44..f123ac983e62 100644 --- a/Makefile +++ b/Makefile @@ -1057,7 +1057,8 @@ ifdef CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT endif endif ifdef CONFIG_HAVE_FENTRY - ifdef CONFIG_CC_HAS_MFENTRY + # s390-linux-gnu-gcc did not support -mfentry until gcc-9. + ifeq ($(call cc-option-yn, -mfentry),y) CC_FLAGS_FTRACE += -mfentry CC_FLAGS_USING += -DCC_USING_FENTRY endif diff --git a/scripts/Kconfig.toolchain b/scripts/Kconfig.toolchain index 254393d4f98a..01b49fa5d6be 100644 --- a/scripts/Kconfig.toolchain +++ b/scripts/Kconfig.toolchain @@ -169,10 +169,6 @@ config CC_OPT_NO_ALLOW_STORE_DATA_RACES config CC_HAS_MNOP_MCOUNT def_bool $(cc-option,-mnop-mcount) -# s390-linux-gnu-gcc did not support -mfentry until gcc-9. -config CC_HAS_MFENTRY - def_bool $(cc-option,-mfentry) - config LD_OPT_FORCE_GROUP_ALLOCATION def_string "$(ld-option-str,--force-group-allocation)" From e58096244338308dde3fa76982c8042981ddda52 Mon Sep 17 00:00:00 2001 From: Nathan Chancellor Date: Tue, 20 Oct 2026 14:52:19 -0700 Subject: [PATCH 2/2] scripts/Kconfig.toolchain: Highlight cc-option differences between Kconfig and Kbuild Performing cc-option checks in Kconfig instead of Kbuild can help speed up incremental builds where the configuration does not change, as the results of the probes can be easily cached. However, there are two potential issues that folks need to consider when using cc-option in Kconfig compared to Kbuild. The first is that in Kbuild, cc-option additions are cumulative, so KBUILD_CFLAGS += $(call cc-option,-mfoo) KBUILD_CFLAGS += $(call cc-option,-mbar) results in '-mbar' being tested with '-mfoo' if it was supported. In Kconfig, '-mbar' would be tested without '-mfoo', which could change the result if '-mbar' depends on '-mfoo' being present, so it would need to test support with $(cc-option,-mbar -mfoo) The second is that the Kconfig stage is where questions like "is the target architecture 32-bit or 64-bit" or "is the target architecture big or little endian" are answered, which very much matters for testing compiler options. Toolchains may be configured for either option, so the kernel needs to pass compiler flags like '-m32', '-m64', '-mlittle-endian', and '-mbig-endian' to properly match a user's configuration choices. Without these flags, '-mfoo' is tested against a toolchain's configured default, resulting in an inconsistent answer to whether the flag is actually supported for the requested configuration. This could manifest as a build breakage from an unexpectedly included but unsupported flag or missing functionality from an unexpected omitted flag. Add a big comment summarizing these two issues to help future travelers. Link: https://patch.msgid.link/20261020-kconfig-fix-mfentry-check-v1-2-428258bc0fc0@kernel.org Signed-off-by: Nathan Chancellor --- scripts/Kconfig.toolchain | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) diff --git a/scripts/Kconfig.toolchain b/scripts/Kconfig.toolchain index 01b49fa5d6be..a99d875489ee 100644 --- a/scripts/Kconfig.toolchain +++ b/scripts/Kconfig.toolchain @@ -144,6 +144,25 @@ config CC_HAS_ASSUME config CC_HAS_NO_PROFILE_FN_ATTR def_bool $(success,echo '__attribute__((no_profile_instrument_function)) int x();' | $(CC) -x c - -c -o /dev/null -Werror) +# Beware of two problems when using cc-option in Kconfig compared to Kbuild +# +# 1. cc-option in Kbuild tests the provided flags with all previously added +# CFLAGS, whereas cc-option in Kconfig only tests the provided flags with a +# small, constant set of additional flags. If a flag (e.g., '-mfoo') +# depends on another (e.g, '-fbar') to function properly, the dependency +# must be included in the cc-option call (e.g, '-fbar -mfoo'). +# +# 2. Bit and endianness flags ('-m32', '-m64', '-mbig-endian', and +# '-mlittle-endian') are not present in Kconfig cc-option checks because +# they may be included in KBUILD_CFLAGS / KBUILD_CPPFLAGS based on the +# finalized configuration result. This can result in inconsistent results +# when probing toolchains that support either option, as the toolchain's +# configured default tested in Kconfig may not support the tested flag but +# the post-configuration result in Kbuild would. +# +# In general, prefer adding truly generic compiler flags to avoid this +# pitfall. + config CC_OPT_ZERO_INIT_PADDING_BITS def_string "$(cc-option-str,-fzero-init-padding-bits=all)"