[PATCH v2 00/10] kbuild: userprogs: introduce architecture-specific CC_CAN_LINK and userprog flags

[PATCH v2 00/10] kbuild: userprogs: introduce architecture-specific CC_CAN_LINK and userprog flags

[Thomas Weißschuh]

The current logic to inherit -m32/-m64 from the kernel build only works
for a few architectures. It does not handle byte order differences,
architectures using different compiler flags or different kinds of ABIs.

Introduce a per-architecture override mechanism to set CC_CAN_LINK and
the flags used for userprogs.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
Changes in v2:
- Rebase and drop already applied patch
- Disable CC_CAN_LINK if the test program generates warnings
- Move to architecture-specific logic
- Link to v1: https://lore.kernel.org/r/20250813-kbuild-userprogs-bits-v1-0-2d9f7f411083@linutronix.de

---
Thomas Weißschuh (10):
      kbuild: don't enable CC_CAN_LINK if the dummy program generates warnings
      init: deduplicate cc-can-link.sh invocations
      kbuild: allow architectures to override CC_CAN_LINK
      riscv: Implement custom CC_CAN_LINK
      s390: Implement custom CC_CAN_LINK
      powerpc: Implement custom CC_CAN_LINK
      MIPS: Implement custom CC_CAN_LINK
      x86/Kconfig: Implement custom CC_CAN_LINK
      sparc: Implement custom CC_CAN_LINK
      kbuild: simplify CC_CAN_LINK

 Makefile                |  8 ++++++--
 arch/mips/Kconfig       | 15 +++++++++++++++
 arch/powerpc/Kconfig    | 15 +++++++++++++++
 arch/riscv/Kconfig      | 11 +++++++++++
 arch/s390/Kconfig       | 11 +++++++++++
 arch/sparc/Kconfig      | 11 +++++++++++
 arch/x86/Kconfig        | 11 +++++++++++
 init/Kconfig            |  7 +++++--
 scripts/Kconfig.include |  3 +++
 scripts/cc-can-link.sh  |  2 +-
 10 files changed, 89 insertions(+), 5 deletions(-)
---
base-commit: 10f8210c7a7098897fcee5ca70236167b39eb797
change-id: 20250813-kbuild-userprogs-bits-03c117da4d50

Best regards,
-- 
Thomas Weißschuh <thomas.weissschuh@linutronix.de>

[PATCH v2 01/10] kbuild: don't enable CC_CAN_LINK if the dummy program generates warnings

[Thomas Weißschuh]

It is possible that the kernel toolchain generates warnings when used
together with the system toolchain. This happens for example when the
older kernel toolchain does not handle new versions of sframe debug
information. While these warnings where ignored during the evaluation
of CC_CAN_LINK, together with CONFIG_WERROR the actual userprog build
will later fail.

Example warning:

.../x86_64-linux/13.2.0/../../../../x86_64-linux/bin/ld:
error in /lib/../lib64/crt1.o(.sframe); no .sframe will be created
collect2: error: ld returned 1 exit status

Make sure that the very simple example program does not generate
warnings already to avoid breaking the userprog compilations.

Fixes: ec4a3992bc0b ("kbuild: respect CONFIG_WERROR for linker and assembler")
Fixes: 3f0ff4cc6ffb ("kbuild: respect CONFIG_WERROR for userprogs")
Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 scripts/cc-can-link.sh | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/cc-can-link.sh b/scripts/cc-can-link.sh
index 6efcead3198989d2ab2ab6772c72d8bb61c89c4e..e67fd8d7b6841e53341045b28dc5196cc1327cbe 100755
--- a/scripts/cc-can-link.sh
+++ b/scripts/cc-can-link.sh
@@ -1,7 +1,7 @@
 #!/bin/sh
 # SPDX-License-Identifier: GPL-2.0
 
-cat << "END" | $@ -x c - -o /dev/null >/dev/null 2>&1
+cat << "END" | $@ -Werror -Wl,--fatal-warnings -x c - -o /dev/null >/dev/null 2>&1
 #include <stdio.h>
 int main(void)
 {

-- 
2.51.0

Re: [PATCH v2 01/10] kbuild: don't enable CC_CAN_LINK if the dummy program generates warnings

[Nicolas Schier]

On Tue, Oct 14, 2025 at 03:05:16PM +0200, Thomas Weißschuh wrote:
> It is possible that the kernel toolchain generates warnings when used
> together with the system toolchain. This happens for example when the
> older kernel toolchain does not handle new versions of sframe debug
> information. While these warnings where ignored during the evaluation
> of CC_CAN_LINK, together with CONFIG_WERROR the actual userprog build
> will later fail.
> 
> Example warning:
> 
> .../x86_64-linux/13.2.0/../../../../x86_64-linux/bin/ld:
> error in /lib/../lib64/crt1.o(.sframe); no .sframe will be created
> collect2: error: ld returned 1 exit status
> 
> Make sure that the very simple example program does not generate
> warnings already to avoid breaking the userprog compilations.
> 
> Fixes: ec4a3992bc0b ("kbuild: respect CONFIG_WERROR for linker and assembler")
> Fixes: 3f0ff4cc6ffb ("kbuild: respect CONFIG_WERROR for userprogs")
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
>  scripts/cc-can-link.sh | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 

Reviewed-by: Nicolas Schier <nsc@kernel.org>

-- 
Nicolas

[PATCH v2 02/10] init: deduplicate cc-can-link.sh invocations

[Thomas Weißschuh]

The command to invoke scripts/cc-can-link.sh is very long and new usages
are about to be added.

Add a helper variable to make the code easier to read and maintain.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 init/Kconfig            | 4 ++--
 scripts/Kconfig.include | 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index cab3ad28ca49e7ac930207c9cde8d431d55dc7af..7b722e714d5c5a0580467914b226dc0700ec0797 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -84,8 +84,8 @@ config RUSTC_LLVM_VERSION
 
 config CC_CAN_LINK
 	bool
-	default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(USERCFLAGS) $(USERLDFLAGS) $(m64-flag)) if 64BIT
-	default $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(USERCFLAGS) $(USERLDFLAGS) $(m32-flag))
+	default $(cc_can_link_user,$(m64-flag)) if 64BIT
+	default $(cc_can_link_user,$(m32-flag))
 
 # Fixed in GCC 14, 13.3, 12.4 and 11.5
 # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
index 33193ca6e8030e659d6b321acaea1acd42c387a4..d42042b6c9e243b46d1626d892c0c986621ce462 100644
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -65,6 +65,9 @@ cc-option-bit = $(if-success,$(CC) -Werror $(1) -E -x c /dev/null -o /dev/null,$
 m32-flag := $(cc-option-bit,-m32)
 m64-flag := $(cc-option-bit,-m64)
 
+# Test whether the compiler can link userspace applications
+cc_can_link_user = $(success,$(srctree)/scripts/cc-can-link.sh $(CC) $(CLANG_FLAGS) $(USERCFLAGS) $(USERLDFLAGS) $(1))
+
 rustc-version := $(shell,$(srctree)/scripts/rustc-version.sh $(RUSTC))
 rustc-llvm-version := $(shell,$(srctree)/scripts/rustc-llvm-version.sh $(RUSTC))
 

-- 
2.51.0

Re: [PATCH v2 02/10] init: deduplicate cc-can-link.sh invocations

[Nicolas Schier]

On Tue, Oct 14, 2025 at 03:05:17PM +0200, Thomas Weißschuh wrote:
> The command to invoke scripts/cc-can-link.sh is very long and new usages
> are about to be added.
> 
> Add a helper variable to make the code easier to read and maintain.
> 
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
>  init/Kconfig            | 4 ++--
>  scripts/Kconfig.include | 3 +++
>  2 files changed, 5 insertions(+), 2 deletions(-)
> 

Reviewed-by: Nicolas Schier <nsc@kernel.org>

-- 
Nicolas

[PATCH v2 03/10] kbuild: allow architectures to override CC_CAN_LINK

[Thomas Weißschuh]

The generic test for CC_CAN_LINK assumes that all architectures use -m32
and -m64 to switch between 32-bit and 64-bit compilation. This is overly
simplistic. Architectures may use other flags (-mabi, -m31, etc.) or may
also require byte order handling (-mlittle-endian, -EL). Expressing all
of the different possibilities will be very complicated and brittle.
Instead allow architectures to supply their own logic which will be
easy to understand and evolve.

Both the boolean ARCH_HAS_CC_CAN_LINK and the string ARCH_USERFLAGS need
to be implemented as kconfig does not allow the reuse of string options.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 Makefile     | 13 +++++++++++--
 init/Kconfig |  4 ++++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 17cfa11ca7163aa3297101ceb3c9e85f4878f12d..26e5bca534e27034c355939bca4c90db435ecdbd 100644
--- a/Makefile
+++ b/Makefile
@@ -1134,8 +1134,17 @@ ifneq ($(CONFIG_ARCH_VMLINUX_NEEDS_RELOCS),)
 LDFLAGS_vmlinux	+= --emit-relocs --discard-none
 endif
 
-# Align the bit size of userspace programs with the kernel
-USERFLAGS_FROM_KERNEL := -m32 -m64 --target=%
+# Align the architecture of userspace programs with the kernel
+USERFLAGS_FROM_KERNEL := --target=%
+
+ifdef CONFIG_ARCH_USERPROGS_CFLAGS
+KBUILD_USERCFLAGS += $(CONFIG_ARCH_USERFLAGS)
+KBUILD_USERLDFLAGS += $(CONFIG_ARCH_USERFLAGS)
+else
+# If not overridden also inherit the bit size
+USERFLAGS_FROM_KERNEL += -m32 -m64
+endif
+
 KBUILD_USERCFLAGS  += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
 KBUILD_USERLDFLAGS += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
 
diff --git a/init/Kconfig b/init/Kconfig
index 7b722e714d5c5a0580467914b226dc0700ec0797..4a2ae3cfbf26525a60936d9b29a74ef4319ba3a5 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -82,8 +82,12 @@ config RUSTC_LLVM_VERSION
 	int
 	default $(rustc-llvm-version)
 
+config ARCH_HAS_CC_CAN_LINK
+	bool
+
 config CC_CAN_LINK
 	bool
+	default ARCH_CC_CAN_LINK if ARCH_HAS_CC_CAN_LINK
 	default $(cc_can_link_user,$(m64-flag)) if 64BIT
 	default $(cc_can_link_user,$(m32-flag))
 

-- 
2.51.0

Re: [PATCH v2 03/10] kbuild: allow architectures to override CC_CAN_LINK

[Nicolas Schier]

On Tue, Oct 14, 2025 at 03:05:18PM +0200, Thomas Weißschuh wrote:
> The generic test for CC_CAN_LINK assumes that all architectures use -m32
> and -m64 to switch between 32-bit and 64-bit compilation. This is overly
> simplistic. Architectures may use other flags (-mabi, -m31, etc.) or may
> also require byte order handling (-mlittle-endian, -EL). Expressing all
> of the different possibilities will be very complicated and brittle.
> Instead allow architectures to supply their own logic which will be
> easy to understand and evolve.
> 
> Both the boolean ARCH_HAS_CC_CAN_LINK and the string ARCH_USERFLAGS need
> to be implemented as kconfig does not allow the reuse of string options.
> 
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
>  Makefile     | 13 +++++++++++--
>  init/Kconfig |  4 ++++
>  2 files changed, 15 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index 17cfa11ca7163aa3297101ceb3c9e85f4878f12d..26e5bca534e27034c355939bca4c90db435ecdbd 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1134,8 +1134,17 @@ ifneq ($(CONFIG_ARCH_VMLINUX_NEEDS_RELOCS),)
>  LDFLAGS_vmlinux	+= --emit-relocs --discard-none
>  endif
>  
> -# Align the bit size of userspace programs with the kernel
> -USERFLAGS_FROM_KERNEL := -m32 -m64 --target=%
> +# Align the architecture of userspace programs with the kernel
> +USERFLAGS_FROM_KERNEL := --target=%
> +
> +ifdef CONFIG_ARCH_USERPROGS_CFLAGS

Is this some left-over from a previous version?

s/CONFIG_ARCH_USERPROGS_CFLAGS/CONFIG_ARCH_USERFLAGS/

Kind regards,
Nicolas

Re: [PATCH v2 03/10] kbuild: allow architectures to override CC_CAN_LINK

[Thomas Weißschuh]

On Wed, Nov 12, 2025 at 08:56:12PM +0100, Nicolas Schier wrote:
> On Tue, Oct 14, 2025 at 03:05:18PM +0200, Thomas Weißschuh wrote:
> > The generic test for CC_CAN_LINK assumes that all architectures use -m32
> > and -m64 to switch between 32-bit and 64-bit compilation. This is overly
> > simplistic. Architectures may use other flags (-mabi, -m31, etc.) or may
> > also require byte order handling (-mlittle-endian, -EL). Expressing all
> > of the different possibilities will be very complicated and brittle.
> > Instead allow architectures to supply their own logic which will be
> > easy to understand and evolve.
> > 
> > Both the boolean ARCH_HAS_CC_CAN_LINK and the string ARCH_USERFLAGS need
> > to be implemented as kconfig does not allow the reuse of string options.
> > 
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > ---
> >  Makefile     | 13 +++++++++++--
> >  init/Kconfig |  4 ++++
> >  2 files changed, 15 insertions(+), 2 deletions(-)
> > 
> > diff --git a/Makefile b/Makefile
> > index 17cfa11ca7163aa3297101ceb3c9e85f4878f12d..26e5bca534e27034c355939bca4c90db435ecdbd 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1134,8 +1134,17 @@ ifneq ($(CONFIG_ARCH_VMLINUX_NEEDS_RELOCS),)
> >  LDFLAGS_vmlinux	+= --emit-relocs --discard-none
> >  endif
> >  
> > -# Align the bit size of userspace programs with the kernel
> > -USERFLAGS_FROM_KERNEL := -m32 -m64 --target=%
> > +# Align the architecture of userspace programs with the kernel
> > +USERFLAGS_FROM_KERNEL := --target=%
> > +
> > +ifdef CONFIG_ARCH_USERPROGS_CFLAGS
> 
> Is this some left-over from a previous version?
> 
> s/CONFIG_ARCH_USERPROGS_CFLAGS/CONFIG_ARCH_USERFLAGS/

Indeed. Thanks.

[PATCH v2 04/10] riscv: Implement custom CC_CAN_LINK

[Thomas Weißschuh]

The generic CC_CAN_LINK detection relies on -m32/-m64 compiler flags.
These are not supported by riscv compilers.

Use architecture-specific logic using -mabi instead.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 arch/riscv/Kconfig | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 0c6038dc5dfd529e1fe623f6bc2729a388b33fde..1faf6e6ec87d1417b4e3213ad54053439c87e331 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -25,6 +25,7 @@ config RISCV
 	select ARCH_ENABLE_SPLIT_PMD_PTLOCK if PGTABLE_LEVELS > 2
 	select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
 	select ARCH_HAS_BINFMT_FLAT
+	select ARCH_HAS_CC_CAN_LINK
 	select ARCH_HAS_CURRENT_STACK_POINTER
 	select ARCH_HAS_DEBUG_VIRTUAL if MMU
 	select ARCH_HAS_DEBUG_VM_PGTABLE
@@ -1335,6 +1336,16 @@ config PORTABLE
 config ARCH_PROC_KCORE_TEXT
 	def_bool y
 
+config ARCH_CC_CAN_LINK
+	bool
+	default $(cc_can_link_user,-mabi=lp64d) if 64BIT
+	default $(cc_can_link_user,-mabi=ilp32d)
+
+config ARCH_USERFLAGS
+	string
+	default "-mabi=lp64d" if 64BIT
+	default "-mabi=ilp32d"
+
 menu "Power management options"
 
 source "kernel/power/Kconfig"

-- 
2.51.0

[PATCH v2 05/10] s390: Implement custom CC_CAN_LINK

[Thomas Weißschuh]

The generic CC_CAN_LINK detection relies on -m32/-m64 compiler flags.
s390 uses -m31 instead of -m32.

Use architecture-specific logic using -m31/-m64 instead.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 arch/s390/Kconfig | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig
index c4145672ca342a656eece10704706d4b12ff9fd6..77ea17537fa2f938aee1fce0053a48853b1ce638 100644
--- a/arch/s390/Kconfig
+++ b/arch/s390/Kconfig
@@ -82,6 +82,7 @@ config S390
 	select ARCH_ENABLE_MEMORY_HOTREMOVE
 	select ARCH_ENABLE_SPLIT_PMD_PTLOCK if PGTABLE_LEVELS > 2
 	select ARCH_ENABLE_THP_MIGRATION if TRANSPARENT_HUGEPAGE
+	select ARCH_HAS_CC_CAN_LINK
 	select ARCH_HAS_CPU_FINALIZE_INIT
 	select ARCH_HAS_CURRENT_STACK_POINTER
 	select ARCH_HAS_DEBUG_VIRTUAL
@@ -290,6 +291,16 @@ config PGTABLE_LEVELS
 
 source "kernel/livepatch/Kconfig"
 
+config ARCH_CC_CAN_LINK
+	bool
+	default $(cc_can_link_user,-m64) if 64BIT
+	default $(cc_can_link_user,-m31)
+
+config ARCH_USERFLAGS
+	string
+	default "-m64" if 64BIT
+	default "-m31"
+
 config ARCH_SUPPORTS_KEXEC
 	def_bool y
 

-- 
2.51.0

[PATCH v2 06/10] powerpc: Implement custom CC_CAN_LINK

[Thomas Weißschuh]

The generic CC_CAN_LINK detection does not handle different byte orders.
This may lead to userprogs which are not actually runnable on the target
kernel.

Use architecture-specific logic supporting byte orders instead.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 arch/powerpc/Kconfig | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index e24f4d88885ae52e77fcb523040e8d31f167571f..c6887a2b97530b9c5b8c34dd0baa3ef8548cb43d 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -127,6 +127,7 @@ config PPC
 	select ARCH_DMA_DEFAULT_COHERENT	if !NOT_COHERENT_CACHE
 	select ARCH_ENABLE_MEMORY_HOTPLUG
 	select ARCH_ENABLE_MEMORY_HOTREMOVE
+	select ARCH_HAS_CC_CAN_LINK
 	select ARCH_HAS_COPY_MC			if PPC64
 	select ARCH_HAS_CURRENT_STACK_POINTER
 	select ARCH_HAS_DEBUG_VIRTUAL
@@ -1341,6 +1342,20 @@ endif
 config PPC_LIB_RHEAP
 	bool
 
+config ARCH_CC_CAN_LINK
+	bool
+	default $(cc_can_link_user,-m64 -mlittle-endian) if 64BIT && CPU_LITTLE_ENDIAN
+	default $(cc_can_link_user,-m64 -mbig-endian) if 64BIT && CPU_BIG_ENDIAN
+	default $(cc_can_link_user,-m32 -mlittle-endian) if CPU_LITTLE_ENDIAN
+	default $(cc_can_link_user,-m32 -mbig-endian) if CPU_BIG_ENDIAN
+
+config ARCH_USERFLAGS
+	string
+	default "-m64 -mlittle-endian" if 64BIT && CPU_LITTLE_ENDIAN
+	default "-m64 -mbig-endian" if 64BIT && CPU_BIG_ENDIAN
+	default "-m32 -mlittle-endian" if CPU_LITTLE_ENDIAN
+	default "-m32 -mbig-endian" if CPU_BIG_ENDIAN
+
 source "arch/powerpc/kvm/Kconfig"
 
 source "kernel/livepatch/Kconfig"

-- 
2.51.0

[PATCH v2 07/10] MIPS: Implement custom CC_CAN_LINK

[Thomas Weißschuh]

The generic CC_CAN_LINK detection does not handle different byte orders.
This may lead to userprogs which are not actually runnable on the target
kernel.

Use architecture-specific logic supporting byte orders instead.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 arch/mips/Kconfig | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index e8683f58fd3e2a43bf9384e1c3c3e454a8e59861..b4f07558ad395eb9bb626a264a2e00fdfbdb7f72 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -4,6 +4,7 @@ config MIPS
 	default y
 	select ARCH_32BIT_OFF_T if !64BIT
 	select ARCH_BINFMT_ELF_STATE if MIPS_FP_SUPPORT
+	select ARCH_HAS_CC_CAN_LINK
 	select ARCH_HAS_CPU_CACHE_ALIASING
 	select ARCH_HAS_CPU_FINALIZE_INIT
 	select ARCH_HAS_CURRENT_STACK_POINTER
@@ -3126,6 +3127,20 @@ config CC_HAS_MNO_BRANCH_LIKELY
 config CC_HAS_BROKEN_INLINE_COMPAT_BRANCH
 	def_bool y if CC_IS_CLANG
 
+config ARCH_CC_CAN_LINK
+	bool
+	default $(cc_can_link_user,-m64 -EL) if 64BIT && CPU_LITTLE_ENDIAN
+	default $(cc_can_link_user,-m64 -EB) if 64BIT && CPU_BIG_ENDIAN
+	default $(cc_can_link_user,-m32 -EL) if CPU_LITTLE_ENDIAN
+	default $(cc_can_link_user,-m32 -EB) if CPU_BIG_ENDIAN
+
+config ARCH_USERFLAGS
+	string
+	default "-m64 -EL" if 64BIT && CPU_LITTLE_ENDIAN
+	default "-m64 -EB" if 64BIT && CPU_BIG_ENDIAN
+	default "-m32 -EL" if CPU_LITTLE_ENDIAN
+	default "-m32 -EB" if CPU_BIG_ENDIAN
+
 menu "Power management options"
 
 config ARCH_HIBERNATION_POSSIBLE

-- 
2.51.0

[PATCH v2 08/10] x86/Kconfig: Implement custom CC_CAN_LINK

[Thomas Weißschuh]

The generic CC_CAN_LINK detection does not work for all architectures.
To make it clearer how the detection works on x86 create an
architecture-specific variant.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 arch/x86/Kconfig | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index fa3b616af03a2d50eaf5f922bc8cd4e08a284045..a98675cd01c0c27e2a5716fb6d051416ddcc956f 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -73,6 +73,7 @@ config X86
 	select ARCH_ENABLE_SPLIT_PMD_PTLOCK if (PGTABLE_LEVELS > 2) && (X86_64 || X86_PAE)
 	select ARCH_ENABLE_THP_MIGRATION if X86_64 && TRANSPARENT_HUGEPAGE
 	select ARCH_HAS_ACPI_TABLE_UPGRADE	if ACPI
+	select ARCH_HAS_CC_CAN_LINK
 	select ARCH_HAS_CPU_ATTACK_VECTORS	if CPU_MITIGATIONS
 	select ARCH_HAS_CACHE_LINE_SIZE
 	select ARCH_HAS_CPU_CACHE_INVALIDATE_MEMREGION
@@ -3171,6 +3172,16 @@ config HAVE_ATOMIC_IOMAP
 	def_bool y
 	depends on X86_32
 
+config ARCH_CC_CAN_LINK
+	bool
+	default $(cc_can_link_user,-m64) if 64BIT
+	default $(cc_can_link_user,-m32)
+
+config ARCH_USERFLAGS
+	string
+	default "-m64" if 64BIT
+	default "-m32"
+
 source "arch/x86/kvm/Kconfig"
 
 source "arch/x86/Kconfig.cpufeatures"

-- 
2.51.0

[PATCH v2 09/10] sparc: Implement custom CC_CAN_LINK

[Thomas Weißschuh]

The generic CC_CAN_LINK detection does not work for all architectures.
To make it clearer how the detection works on SPARC create an
architecture-specific variant.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 arch/sparc/Kconfig | 11 +++++++++++
 1 file changed, 11 insertions(+)

diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index a630d373e6453c745ab8bf58fc5622cf0edaf4c9..68b553a47d039da4368a2de30168aaf80a941148 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -13,6 +13,7 @@ config 64BIT
 config SPARC
 	bool
 	default y
+	select ARCH_HAS_CC_CAN_LINK
 	select ARCH_HAS_CPU_CACHE_ALIASING
 	select ARCH_HAS_DMA_OPS
 	select ARCH_MIGHT_HAVE_PC_PARPORT if SPARC64 && PCI
@@ -475,4 +476,14 @@ config COMPAT
 	select ARCH_WANT_OLD_COMPAT_IPC
 	select COMPAT_OLD_SIGACTION
 
+config ARCH_CC_CAN_LINK
+	bool
+	default $(cc_can_link_user,-m64) if 64BIT
+	default $(cc_can_link_user,-m32)
+
+config ARCH_USERFLAGS
+	string
+	default "-m64" if 64BIT
+	default "-m32"
+
 source "drivers/sbus/char/Kconfig"

-- 
2.51.0

[PATCH v2 10/10] kbuild: simplify CC_CAN_LINK

[Thomas Weißschuh]

All architectures supporting multiple ABIs have been migrated to
ARCH_CC_CAN_LINK. The remaining ones do not require any special flag,
so simplify the logic.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
---
 Makefile     | 11 +++--------
 init/Kconfig |  3 +--
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/Makefile b/Makefile
index 26e5bca534e27034c355939bca4c90db435ecdbd..1b7da9f10b88f1a374ae34477e5621b4dd27c017 100644
--- a/Makefile
+++ b/Makefile
@@ -1137,17 +1137,12 @@ endif
 # Align the architecture of userspace programs with the kernel
 USERFLAGS_FROM_KERNEL := --target=%
 
-ifdef CONFIG_ARCH_USERPROGS_CFLAGS
-KBUILD_USERCFLAGS += $(CONFIG_ARCH_USERFLAGS)
-KBUILD_USERLDFLAGS += $(CONFIG_ARCH_USERFLAGS)
-else
-# If not overridden also inherit the bit size
-USERFLAGS_FROM_KERNEL += -m32 -m64
-endif
-
 KBUILD_USERCFLAGS  += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
 KBUILD_USERLDFLAGS += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
 
+KBUILD_USERCFLAGS += $(CONFIG_ARCH_USERFLAGS)
+KBUILD_USERLDFLAGS += $(CONFIG_ARCH_USERFLAGS)
+
 # userspace programs are linked via the compiler, use the correct linker
 ifdef CONFIG_CC_IS_CLANG
 KBUILD_USERLDFLAGS += --ld-path=$(LD)
diff --git a/init/Kconfig b/init/Kconfig
index 4a2ae3cfbf26525a60936d9b29a74ef4319ba3a5..a0127598f2f25ffb55dbb8a0691b0aa68138fc69 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -88,8 +88,7 @@ config ARCH_HAS_CC_CAN_LINK
 config CC_CAN_LINK
 	bool
 	default ARCH_CC_CAN_LINK if ARCH_HAS_CC_CAN_LINK
-	default $(cc_can_link_user,$(m64-flag)) if 64BIT
-	default $(cc_can_link_user,$(m32-flag))
+	default $(cc_can_link_user)
 
 # Fixed in GCC 14, 13.3, 12.4 and 11.5
 # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921

-- 
2.51.0

Re: [PATCH v2 10/10] kbuild: simplify CC_CAN_LINK

[Nicolas Schier]

On Tue, Oct 14, 2025 at 03:05:25PM +0200, Thomas Weißschuh wrote:
> All architectures supporting multiple ABIs have been migrated to
> ARCH_CC_CAN_LINK. The remaining ones do not require any special flag,
> so simplify the logic.
> 
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
>  Makefile     | 11 +++--------
>  init/Kconfig |  3 +--
>  2 files changed, 4 insertions(+), 10 deletions(-)
> 

Reviewed-by: Nicolas Schier <nsc@kernel.org>

-- 
Nicolas

Re: [PATCH v2 00/10] kbuild: userprogs: introduce architecture-specific CC_CAN_LINK and userprog flags

[Nicolas Schier]

On Tue, Oct 14, 2025 at 03:05:15PM +0200, Thomas Weißschuh wrote:
> The current logic to inherit -m32/-m64 from the kernel build only works
> for a few architectures. It does not handle byte order differences,
> architectures using different compiler flags or different kinds of ABIs.
> 
> Introduce a per-architecture override mechanism to set CC_CAN_LINK and
> the flags used for userprogs.
> 
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> ---
> Changes in v2:
> - Rebase and drop already applied patch
> - Disable CC_CAN_LINK if the test program generates warnings
> - Move to architecture-specific logic
> - Link to v1: https://lore.kernel.org/r/20250813-kbuild-userprogs-bits-v1-0-2d9f7f411083@linutronix.de
> 
> ---
> Thomas Weißschuh (10):
>       kbuild: don't enable CC_CAN_LINK if the dummy program generates warnings
>       init: deduplicate cc-can-link.sh invocations
>       kbuild: allow architectures to override CC_CAN_LINK
>       riscv: Implement custom CC_CAN_LINK
>       s390: Implement custom CC_CAN_LINK
>       powerpc: Implement custom CC_CAN_LINK
>       MIPS: Implement custom CC_CAN_LINK
>       x86/Kconfig: Implement custom CC_CAN_LINK
>       sparc: Implement custom CC_CAN_LINK
>       kbuild: simplify CC_CAN_LINK
> 
>  Makefile                |  8 ++++++--
>  arch/mips/Kconfig       | 15 +++++++++++++++
>  arch/powerpc/Kconfig    | 15 +++++++++++++++
>  arch/riscv/Kconfig      | 11 +++++++++++
>  arch/s390/Kconfig       | 11 +++++++++++
>  arch/sparc/Kconfig      | 11 +++++++++++
>  arch/x86/Kconfig        | 11 +++++++++++
>  init/Kconfig            |  7 +++++--
>  scripts/Kconfig.include |  3 +++
>  scripts/cc-can-link.sh  |  2 +-
>  10 files changed, 89 insertions(+), 5 deletions(-)
> ---
> base-commit: 10f8210c7a7098897fcee5ca70236167b39eb797
> change-id: 20250813-kbuild-userprogs-bits-03c117da4d50
> 
> Best regards,
> -- 
> Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> 

Thanks for the patch set and all the work behind!  I found only one
issue in patch 3, the rest looks good to me as they are.

I haven't reviewed the compiler flags for the archs, but from the formal
point of view they look good to me, too.

How shall we proceed with here?  I think, easiest would be if we get
appropriate acks from the architecture maintainers, so we could take
this via kbuild.

Other opinions?

Kind regards,
Nicolas

Re: [PATCH v2 00/10] kbuild: userprogs: introduce architecture-specific CC_CAN_LINK and userprog flags

[Thomas Weißschuh]

On Wed, Nov 12, 2025 at 09:03:23PM +0100, Nicolas Schier wrote:
> On Tue, Oct 14, 2025 at 03:05:15PM +0200, Thomas Weißschuh wrote:
> > The current logic to inherit -m32/-m64 from the kernel build only works
> > for a few architectures. It does not handle byte order differences,
> > architectures using different compiler flags or different kinds of ABIs.
> > 
> > Introduce a per-architecture override mechanism to set CC_CAN_LINK and
> > the flags used for userprogs.
> > 
> > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > ---
> > Changes in v2:
> > - Rebase and drop already applied patch
> > - Disable CC_CAN_LINK if the test program generates warnings
> > - Move to architecture-specific logic
> > - Link to v1: https://lore.kernel.org/r/20250813-kbuild-userprogs-bits-v1-0-2d9f7f411083@linutronix.de
> > 
> > ---
> > Thomas Weißschuh (10):
> >       kbuild: don't enable CC_CAN_LINK if the dummy program generates warnings
> >       init: deduplicate cc-can-link.sh invocations
> >       kbuild: allow architectures to override CC_CAN_LINK
> >       riscv: Implement custom CC_CAN_LINK
> >       s390: Implement custom CC_CAN_LINK
> >       powerpc: Implement custom CC_CAN_LINK
> >       MIPS: Implement custom CC_CAN_LINK
> >       x86/Kconfig: Implement custom CC_CAN_LINK
> >       sparc: Implement custom CC_CAN_LINK
> >       kbuild: simplify CC_CAN_LINK
> > 
> >  Makefile                |  8 ++++++--
> >  arch/mips/Kconfig       | 15 +++++++++++++++
> >  arch/powerpc/Kconfig    | 15 +++++++++++++++
> >  arch/riscv/Kconfig      | 11 +++++++++++
> >  arch/s390/Kconfig       | 11 +++++++++++
> >  arch/sparc/Kconfig      | 11 +++++++++++
> >  arch/x86/Kconfig        | 11 +++++++++++
> >  init/Kconfig            |  7 +++++--
> >  scripts/Kconfig.include |  3 +++
> >  scripts/cc-can-link.sh  |  2 +-
> >  10 files changed, 89 insertions(+), 5 deletions(-)
> > ---
> > base-commit: 10f8210c7a7098897fcee5ca70236167b39eb797
> > change-id: 20250813-kbuild-userprogs-bits-03c117da4d50
> > 
> > Best regards,
> > -- 
> > Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > 
> 
> Thanks for the patch set and all the work behind!  I found only one
> issue in patch 3, the rest looks good to me as they are.
> 
> I haven't reviewed the compiler flags for the archs, but from the formal
> point of view they look good to me, too.
> 
> How shall we proceed with here?  I think, easiest would be if we get
> appropriate acks from the architecture maintainers, so we could take
> this via kbuild.

That would surely be the best option. Unfortunately quite frequently it is hard
to get architecture maintainer's feedback on a cross-architecture series.

> Other opinions?

It would also work to only take the first three patches through the kbuild tree
and push the other ones through the architecture trees.

I don't really have a clear preference.


Thomas