Make sure the byte order and ABI of the userprogs matches the one of the
kernel, similar to how the bit size is handled.
Otherwise the userprogs may not be executable.
This happens for example on powerpc little endian, or riscv32.

Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
Reviewed-by: Nicolas Schier <n.schier@avm.de>
Acked-by: Masahiro Yamada <masahiroy@kernel.org>

---
Difference to original series:
* Also handle -EL/-EB for MIPS
---
 Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index d0f5262a9c0f3b4aa79a91c20cc149d034ffa0b7..7d40f84d5efde18ed3a2f4d8cf7a9b1ec3610ed4 100644
--- a/Makefile
+++ b/Makefile
@@ -1137,8 +1137,8 @@ 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 bit size, byte order and architecture of userspace programs with the kernel
+USERFLAGS_FROM_KERNEL := -m32 -m64 -mlittle-endian -mbig-endian -EL -EB --target=% -march=% -mabi=%
 KBUILD_USERCFLAGS  += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
 KBUILD_USERLDFLAGS += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
 

-- 
2.50.1

Hi!

On Wed, Aug 13, 2025 at 07:43:41AM +0200, Thomas Weißschuh wrote:
> Make sure the byte order and ABI of the userprogs matches the one of the
> kernel, similar to how the bit size is handled.
> Otherwise the userprogs may not be executable.
> This happens for example on powerpc little endian, or riscv32.
> 
> Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> Reviewed-by: Nicolas Schier <n.schier@avm.de>
> Acked-by: Masahiro Yamada <masahiroy@kernel.org>
> 
> ---
> Difference to original series:
> * Also handle -EL/-EB for MIPS
> ---
>  Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Makefile b/Makefile
> index d0f5262a9c0f3b4aa79a91c20cc149d034ffa0b7..7d40f84d5efde18ed3a2f4d8cf7a9b1ec3610ed4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1137,8 +1137,8 @@ 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 bit size, byte order and architecture of userspace programs with the kernel
> +USERFLAGS_FROM_KERNEL := -m32 -m64 -mlittle-endian -mbig-endian -EL -EB --target=% -march=% -mabi=%
>  KBUILD_USERCFLAGS  += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
>  KBUILD_USERLDFLAGS += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))

I looked some more at the breakage reported from -next [0].
For architectures with multiple possible byte orders or ABIs the toolchain
might be able to build the kernel for all combinations but might not have a
matching libc for them. Currently userprogs uses the default byteorder and
ABI from the compiler, which will match the included libcs if there is any.
However the resulting binary might not run on the built kernel.
CC_CAN_LINK can be extended to generically handle different byte orders, as
for those we have standard kconfig symbols. But handling ABIs would need to
be architecture specific and a bit more complex.

We can't use KBUILD_*FLAGS for CC_CAN_LINK, as they are not yet set during
the configuration stage.

I see the following options:

* Add byte order and architecture-specific ABI handling to CC_CAN_LINK
* Accept that userprogs might not be runnable on the built kernel
* Let the user manually set CC_CAN_LINK to override the autodetection
* Add separate handling for runnable userprogs
* Use tools/include/nolibc/ for userprogs instead of the toolchain libc
  (unlikely, but I wanted do mention the option)


Thomas

[0] https://lore.kernel.org/lkml/20250818140143.61b8c466@canb.auug.org.au/

Hi Thomas,

On Wed, Aug 27, 2025 at 08:31:00AM +0200, Thomas Weißschuh wrote:
> On Wed, Aug 13, 2025 at 07:43:41AM +0200, Thomas Weißschuh wrote:
...
> > diff --git a/Makefile b/Makefile
> > index d0f5262a9c0f3b4aa79a91c20cc149d034ffa0b7..7d40f84d5efde18ed3a2f4d8cf7a9b1ec3610ed4 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -1137,8 +1137,8 @@ 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 bit size, byte order and architecture of userspace programs with the kernel
> > +USERFLAGS_FROM_KERNEL := -m32 -m64 -mlittle-endian -mbig-endian -EL -EB --target=% -march=% -mabi=%
> >  KBUILD_USERCFLAGS  += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
> >  KBUILD_USERLDFLAGS += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
> 
> I looked some more at the breakage reported from -next [0].

Thanks for looking into this.

> For architectures with multiple possible byte orders or ABIs the toolchain
> might be able to build the kernel for all combinations but might not have a
> matching libc for them. Currently userprogs uses the default byteorder and
> ABI from the compiler, which will match the included libcs if there is any.
> However the resulting binary might not run on the built kernel.
> CC_CAN_LINK can be extended to generically handle different byte orders, as
> for those we have standard kconfig symbols. But handling ABIs would need to
> be architecture specific and a bit more complex.
> 
> We can't use KBUILD_*FLAGS for CC_CAN_LINK, as they are not yet set during
> the configuration stage.

Right, this was the biggest thing that I noticed, which would really
help us out...

> I see the following options:
> 
> * Add byte order and architecture-specific ABI handling to CC_CAN_LINK

How do you envision this? Different default lines for each combination?
Feels like that could get complicated quickly but this would probably be
the objectively most robust and "hands off" option.

> * Accept that userprogs might not be runnable on the built kernel

I do wonder how common running the userprogs are. Obviously you hit this
in testing but I am curious if others have reported this.

> * Let the user manually set CC_CAN_LINK to override the autodetection

I am not sure I like this one but maybe we could have a hidden
CC_MAY_LINK with something like the current CC_CAN_LINK then CC_CAN_LINK
could be turned into something like

    config CC_CAN_LINK
        bool "Toolchain can link userspace executables" if !COMPILE_TEST
        default CC_MAY_LINK

I am not surethat would actually help us here plus I still do not like
the idea of throwing this back to the user.

> * Add separate handling for runnable userprogs

What do you mean by this?

> * Use tools/include/nolibc/ for userprogs instead of the toolchain libc
>   (unlikely, but I wanted do mention the option)

This could be interesting to explore but I assume using a cross libc
could be desirable for some people depending on the testing?

Cheers,
Nathan

On Wed, Aug 27, 2025 at 03:49:35PM -0700, Nathan Chancellor wrote:
> On Wed, Aug 27, 2025 at 08:31:00AM +0200, Thomas Weißschuh wrote:
> > On Wed, Aug 13, 2025 at 07:43:41AM +0200, Thomas Weißschuh wrote:
> ...
> > > diff --git a/Makefile b/Makefile
> > > index d0f5262a9c0f3b4aa79a91c20cc149d034ffa0b7..7d40f84d5efde18ed3a2f4d8cf7a9b1ec3610ed4 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -1137,8 +1137,8 @@ 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 bit size, byte order and architecture of userspace programs with the kernel
> > > +USERFLAGS_FROM_KERNEL := -m32 -m64 -mlittle-endian -mbig-endian -EL -EB --target=% -march=% -mabi=%
> > >  KBUILD_USERCFLAGS  += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))
> > >  KBUILD_USERLDFLAGS += $(filter $(USERFLAGS_FROM_KERNEL), $(KBUILD_CPPFLAGS) $(KBUILD_CFLAGS))

(...)

> > For architectures with multiple possible byte orders or ABIs the toolchain
> > might be able to build the kernel for all combinations but might not have a
> > matching libc for them. Currently userprogs uses the default byteorder and
> > ABI from the compiler, which will match the included libcs if there is any.
> > However the resulting binary might not run on the built kernel.
> > CC_CAN_LINK can be extended to generically handle different byte orders, as
> > for those we have standard kconfig symbols. But handling ABIs would need to
> > be architecture specific and a bit more complex.
> > 
> > We can't use KBUILD_*FLAGS for CC_CAN_LINK, as they are not yet set during
> > the configuration stage.
> 
> Right, this was the biggest thing that I noticed, which would really
> help us out...
> 
> > I see the following options:
> > 
> > * Add byte order and architecture-specific ABI handling to CC_CAN_LINK
> 
> How do you envision this? Different default lines for each combination?

Exactly. The normal cases can be handled generically. For example the kconfig
below works for architectures which only differ in byte order and 32bit/64bit,
which are most of them. MIPS should require more logic.
Also I'm ignoring x32, as it is never the kernel's native ABI.

 config CC_CAN_LINK
        bool
+       default $(cc_can_link_user,$(m64-flag) -mlittle-endian) if 64BIT && CPU_LITTLE_ENDIAN
+       default $(cc_can_link_user,$(m64-flag) -mbig-endian) if 64BIT && CPU_BIG_ENDIAN
        default $(cc_can_link_user,$(m64-flag)) if 64BIT
+       default $(cc_can_link_user,$(m32-flag) -mlittle-endian) if CPU_LITTLE_ENDIAN
+       default $(cc_can_link_user,$(m32-flag) -mbig-endian) if CPU_BIG_ENDIAN
        default $(cc_can_link_user,$(m32-flag))


> Feels like that could get complicated quickly but this would probably be
> the objectively most robust and "hands off" option.

Agreed.

> > * Accept that userprogs might not be runnable on the built kernel
> 
> I do wonder how common running the userprogs are. Obviously you hit this
> in testing but I am curious if others have reported this.

I'm not aware of any reports. Usage of userprogs seems to be fairly low in
general, judging by the issues I ran into which nobody reported or fixed
before. One of the original reasons for the introduction of userprogs were
usermode drivers. These indeed required execution. But the whole framework
was removed recently, although it might come back at some point.

> > * Let the user manually set CC_CAN_LINK to override the autodetection

(...)

> I am not surethat would actually help us here plus I still do not like
> the idea of throwing this back to the user.

Agreed. My personal preference would be my proposal from above.

> > * Add separate handling for runnable userprogs
> 
> What do you mean by this?

I see two possibilities.
* New kconfig and FLAGS mirroring the existing ones to build runnable
  userprogs.
* Introspection of the userprog executable ELF to see if it can run on the
  current kernel configuration.

> > * Use tools/include/nolibc/ for userprogs instead of the toolchain libc
> >   (unlikely, but I wanted do mention the option)
> 
> This could be interesting to explore but I assume using a cross libc
> could be desirable for some people depending on the testing?

Yes, probably. Although the test code in samples/ should interact directly with
the kernel, without much involvement from libc.


Thomas

On Mon, Sep 01, 2025 at 11:51:03AM +0200, Thomas Weißschuh wrote:
> Exactly. The normal cases can be handled generically. For example the kconfig
> below works for architectures which only differ in byte order and 32bit/64bit,
> which are most of them. MIPS should require more logic.
> Also I'm ignoring x32, as it is never the kernel's native ABI.
> 
>  config CC_CAN_LINK
>         bool
> +       default $(cc_can_link_user,$(m64-flag) -mlittle-endian) if 64BIT && CPU_LITTLE_ENDIAN
> +       default $(cc_can_link_user,$(m64-flag) -mbig-endian) if 64BIT && CPU_BIG_ENDIAN
>         default $(cc_can_link_user,$(m64-flag)) if 64BIT
> +       default $(cc_can_link_user,$(m32-flag) -mlittle-endian) if CPU_LITTLE_ENDIAN
> +       default $(cc_can_link_user,$(m32-flag) -mbig-endian) if CPU_BIG_ENDIAN
>         default $(cc_can_link_user,$(m32-flag))
> 
> 
> > Feels like that could get complicated quickly but this would probably be
> > the objectively most robust and "hands off" option.
> 
> Agreed.

Nicolas might feel differently but this does not seem terrible to me,
especially with a macro to wrap the common logic, which is where I felt
like things could get unwieldy. Feel free to send an RFC if it is not
too much work.

Cheers,
Nathan

Hi Nicolas and Nathan,

On Wed, Sep 03, 2025 at 03:31:31PM -0700, Nathan Chancellor wrote:
> On Mon, Sep 01, 2025 at 11:51:03AM +0200, Thomas Weißschuh wrote:
> > Exactly. The normal cases can be handled generically. For example the kconfig
> > below works for architectures which only differ in byte order and 32bit/64bit,
> > which are most of them. MIPS should require more logic.
> > Also I'm ignoring x32, as it is never the kernel's native ABI.
> > 
> >  config CC_CAN_LINK
> >         bool
> > +       default $(cc_can_link_user,$(m64-flag) -mlittle-endian) if 64BIT && CPU_LITTLE_ENDIAN
> > +       default $(cc_can_link_user,$(m64-flag) -mbig-endian) if 64BIT && CPU_BIG_ENDIAN
> >         default $(cc_can_link_user,$(m64-flag)) if 64BIT
> > +       default $(cc_can_link_user,$(m32-flag) -mlittle-endian) if CPU_LITTLE_ENDIAN
> > +       default $(cc_can_link_user,$(m32-flag) -mbig-endian) if CPU_BIG_ENDIAN
> >         default $(cc_can_link_user,$(m32-flag))
> > 
> > 
> > > Feels like that could get complicated quickly but this would probably be
> > > the objectively most robust and "hands off" option.
> > 
> > Agreed.
> 
> Nicolas might feel differently but this does not seem terrible to me,
> especially with a macro to wrap the common logic, which is where I felt
> like things could get unwieldy. Feel free to send an RFC if it is not
> too much work.

I investigated this some more and didn't really like the end result. The
problem is that $(m32-flag) and $(m64-flag) will expand to nothing if the
compiler does not support -m32/-m64. So for architectures which use
different flags the current logic will just ignore the bitness. One way
around this would be a mapping from -m32/-m64 to architecture-specific
flags inside cc-can-link.sh, similar to what I already did before for
the mapping of -mlittle-endian to -EL on MIPS. But we'll end up with a
bunch of architecture-specific details hidden away in a non-generic
shellscript. And the interactions are very non-obvious and brittle.
Then I'd rather have the architecture-specific bits openly in proper
architecture code.

See my current proposal, using x86 as example below. It will require
code for each architecture, but there are not that many of them.
And the configuration matrix for each architecture only contains a
relative small set of actually supported configurations.
Unfortunately I don't see a generic way to deduplicate the flag values
between ARCH_CC_CAN_LINK ARCH_USERPROGS_CFLAGS. Each architecture can
use a macro if they so prefer.

When the "interesting" architectures are done we can also slim down the
generic implementation to not use any special arguments and that would
be enough for the simple architectures.

For the future I would like to introduce CC_CAN_LINK_STATIC again.
With the scheme from below this would mean to duplicate all the kconfig
symbols for each architecture again. One way around would be to change
ARCH_CC_CAN_LINK from bool to string. And then let cc-can-link.sh test
for both static and dynamic linking in one go and return either
"dynamic,static", "dynamic" or "static" which then can be mapped to
CC_CAN_LINK and CC_CAN_LINK_STATIC by generic logic.

What do you think?


diff --git a/Makefile b/Makefile
index d37dca7850b3..17123948a4fa 100644
--- a/Makefile
+++ b/Makefile
@@ -1135,7 +1135,15 @@ LDFLAGS_vmlinux	+= --emit-relocs --discard-none
 endif
 
 # Align the bit size of userspace programs with the kernel
-USERFLAGS_FROM_KERNEL := -m32 -m64 --target=%
+USERFLAGS_FROM_KERNEL := --target=%
+
+ifdef CONFIG_ARCH_USERPROGS_CFLAGS
+KBUILD_USERCFLAGS += $(CONFIG_ARCH_USERPROGS_CFLAGS)
+KBUILD_USERLDFLAGS += $(CONFIG_ARCH_USERPROGS_CFLAGS)
+else
+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/arch/x86/Kconfig b/arch/x86/Kconfig
index 75f3de70df51..162c71c117bc 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -332,6 +332,17 @@ config X86
 	select SCHED_SMT			if SMP
 	select ARCH_SUPPORTS_SCHED_CLUSTER	if SMP
 	select ARCH_SUPPORTS_SCHED_MC		if SMP
+	select ARCH_HAS_CC_CAN_LINK
+
+config ARCH_CC_CAN_LINK
+	bool
+	default $(cc_can_link_user,-m64) if 64BIT
+	default $(cc_can_link_user,-m32) if !64BIT
+
+config ARCH_USERPROGS_CFLAGS
+	string
+	default "-m64" if 64BIT
+	default "-m32" if !64BIT
 
 config INSTRUCTION_DECODER
 	def_bool y
diff --git a/init/Kconfig b/init/Kconfig
index f3b13463ec26..5ca2f3289020 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -82,8 +82,13 @@ config RUSTC_LLVM_VERSION
 	int
 	default $(rustc-llvm-version)
 
+# Might be removed when all architectures are migrated
+config ARCH_HAS_CC_CAN_LINK
+	bool
+
 config CC_CAN_LINK
 	bool
+	default ARCH_CC_CAN_LINK if ARCH_HAS_CC_CAN_LINK
 	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))
 
diff --git a/scripts/Kconfig.include b/scripts/Kconfig.include
index 33193ca6e803..0c8dbfbce415 100644
--- a/scripts/Kconfig.include
+++ b/scripts/Kconfig.include
@@ -75,3 +75,6 @@ rustc-llvm-version := $(shell,$(srctree)/scripts/rustc-llvm-version.sh $(RUSTC))
 # If you are testing for unstable features, consider testing RUSTC_VERSION
 # instead, as features may have different completeness while available.
 rustc-option = $(success,trap "rm -rf .tmp_$$" EXIT; mkdir .tmp_$$; $(RUSTC) $(1) --crate-type=rlib /dev/null --out-dir=.tmp_$$ -o .tmp_$$/tmp.rlib)
+
+# 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))

On Thu, Oct 02, 2025 at 03:23:08PM +0200, Thomas Weißschuh wrote:
> Hi Nicolas and Nathan,
> 
> On Wed, Sep 03, 2025 at 03:31:31PM -0700, Nathan Chancellor wrote:
> > On Mon, Sep 01, 2025 at 11:51:03AM +0200, Thomas Weißschuh wrote:
> > > Exactly. The normal cases can be handled generically. For example the kconfig
> > > below works for architectures which only differ in byte order and 32bit/64bit,
> > > which are most of them. MIPS should require more logic.
> > > Also I'm ignoring x32, as it is never the kernel's native ABI.
> > > 
> > >  config CC_CAN_LINK
> > >         bool
> > > +       default $(cc_can_link_user,$(m64-flag) -mlittle-endian) if 64BIT && CPU_LITTLE_ENDIAN
> > > +       default $(cc_can_link_user,$(m64-flag) -mbig-endian) if 64BIT && CPU_BIG_ENDIAN
> > >         default $(cc_can_link_user,$(m64-flag)) if 64BIT
> > > +       default $(cc_can_link_user,$(m32-flag) -mlittle-endian) if CPU_LITTLE_ENDIAN
> > > +       default $(cc_can_link_user,$(m32-flag) -mbig-endian) if CPU_BIG_ENDIAN
> > >         default $(cc_can_link_user,$(m32-flag))
> > > 
> > > 
> > > > Feels like that could get complicated quickly but this would probably be
> > > > the objectively most robust and "hands off" option.
> > > 
> > > Agreed.
> > 
> > Nicolas might feel differently but this does not seem terrible to me,
> > especially with a macro to wrap the common logic, which is where I felt
> > like things could get unwieldy. Feel free to send an RFC if it is not
> > too much work.
> 
> I investigated this some more and didn't really like the end result. The
> problem is that $(m32-flag) and $(m64-flag) will expand to nothing if the
> compiler does not support -m32/-m64. So for architectures which use
> different flags the current logic will just ignore the bitness. One way
> around this would be a mapping from -m32/-m64 to architecture-specific
> flags inside cc-can-link.sh, similar to what I already did before for
> the mapping of -mlittle-endian to -EL on MIPS. But we'll end up with a
> bunch of architecture-specific details hidden away in a non-generic
> shellscript. And the interactions are very non-obvious and brittle.
> Then I'd rather have the architecture-specific bits openly in proper
> architecture code.

yes, thanks for trying and the verbose feedback.  I think you're right,
it's better to not hide the architecture-specific details.

> See my current proposal, using x86 as example below. It will require
> code for each architecture, but there are not that many of them.
> And the configuration matrix for each architecture only contains a
> relative small set of actually supported configurations.
> Unfortunately I don't see a generic way to deduplicate the flag values
> between ARCH_CC_CAN_LINK ARCH_USERPROGS_CFLAGS. Each architecture can
> use a macro if they so prefer.
> 
> When the "interesting" architectures are done we can also slim down the
> generic implementation to not use any special arguments and that would
> be enough for the simple architectures.
> 
> For the future I would like to introduce CC_CAN_LINK_STATIC again.
> With the scheme from below this would mean to duplicate all the kconfig
> symbols for each architecture again. One way around would be to change
> ARCH_CC_CAN_LINK from bool to string. And then let cc-can-link.sh test
> for both static and dynamic linking in one go and return either
> "dynamic,static", "dynamic" or "static" which then can be mapped to
> CC_CAN_LINK and CC_CAN_LINK_STATIC by generic logic.
> 
> What do you think?

Thanks for all the effort, your proposal sounds good to me and I think
it is a good way forward.

Please call out if you want active support.

Kind regards,
Nicolas

On Wed, Sep 03, 2025 at 03:31:31PM -0700, Nathan Chancellor wrote:
> On Mon, Sep 01, 2025 at 11:51:03AM +0200, Thomas Weißschuh wrote:
> > Exactly. The normal cases can be handled generically. For example the kconfig
> > below works for architectures which only differ in byte order and 32bit/64bit,
> > which are most of them. MIPS should require more logic.
> > Also I'm ignoring x32, as it is never the kernel's native ABI.
> > 
> >  config CC_CAN_LINK
> >         bool
> > +       default $(cc_can_link_user,$(m64-flag) -mlittle-endian) if 64BIT && CPU_LITTLE_ENDIAN
> > +       default $(cc_can_link_user,$(m64-flag) -mbig-endian) if 64BIT && CPU_BIG_ENDIAN
> >         default $(cc_can_link_user,$(m64-flag)) if 64BIT
> > +       default $(cc_can_link_user,$(m32-flag) -mlittle-endian) if CPU_LITTLE_ENDIAN
> > +       default $(cc_can_link_user,$(m32-flag) -mbig-endian) if CPU_BIG_ENDIAN
> >         default $(cc_can_link_user,$(m32-flag))
> > 
> > 
> > > Feels like that could get complicated quickly but this would probably be
> > > the objectively most robust and "hands off" option.
> > 
> > Agreed.
> 
> Nicolas might feel differently but this does not seem terrible to me,
> especially with a macro to wrap the common logic, which is where I felt
> like things could get unwieldy. Feel free to send an RFC if it is not
> too much work.

yes, at a first glance this looks ok to me, too.

Thanks,
Nicolas

On Sun, Sep 07, 2025 at 07:24:07AM +0200, Nicolas Schier wrote:
> On Wed, Sep 03, 2025 at 03:31:31PM -0700, Nathan Chancellor wrote:
> > On Mon, Sep 01, 2025 at 11:51:03AM +0200, Thomas Weißschuh wrote:
> > > Exactly. The normal cases can be handled generically. For example the kconfig
> > > below works for architectures which only differ in byte order and 32bit/64bit,
> > > which are most of them. MIPS should require more logic.
> > > Also I'm ignoring x32, as it is never the kernel's native ABI.
> > > 
> > >  config CC_CAN_LINK
> > >         bool
> > > +       default $(cc_can_link_user,$(m64-flag) -mlittle-endian) if 64BIT && CPU_LITTLE_ENDIAN
> > > +       default $(cc_can_link_user,$(m64-flag) -mbig-endian) if 64BIT && CPU_BIG_ENDIAN
> > >         default $(cc_can_link_user,$(m64-flag)) if 64BIT
> > > +       default $(cc_can_link_user,$(m32-flag) -mlittle-endian) if CPU_LITTLE_ENDIAN
> > > +       default $(cc_can_link_user,$(m32-flag) -mbig-endian) if CPU_BIG_ENDIAN
> > >         default $(cc_can_link_user,$(m32-flag))
> > > 
> > > 
> > > > Feels like that could get complicated quickly but this would probably be
> > > > the objectively most robust and "hands off" option.
> > > 
> > > Agreed.
> > 
> > Nicolas might feel differently but this does not seem terrible to me,
> > especially with a macro to wrap the common logic, which is where I felt
> > like things could get unwieldy. Feel free to send an RFC if it is not
> > too much work.
> 
> yes, at a first glance this looks ok to me, too.

Ack. I'll take a shot at this, but it I might only get around to it next cycle.


Thomas