[PATCH] powerpc: Implement ARCH_HAS_CC_CAN_LINK

[PATCH] powerpc: Implement ARCH_HAS_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 9537a61ebae0..6bb2f90e97ea 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
@@ -1342,6 +1343,20 @@ endif
 config PPC_LIB_RHEAP
 	bool
 
+config ARCH_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,$(m32-flag) -mlittle-endian) if CPU_LITTLE_ENDIAN
+	default $(cc_can_link_user,$(m32-flag) -mbig-endian) if CPU_BIG_ENDIAN
+
+config ARCH_USERFLAGS
+	string
+	default "$(m64-flag) -mlittle-endian" if 64BIT && CPU_LITTLE_ENDIAN
+	default "$(m64-flag) -mbig-endian" if 64BIT && CPU_BIG_ENDIAN
+	default "$(m32-flag) -mlittle-endian" if CPU_LITTLE_ENDIAN
+	default "$(m32-flag) -mbig-endian" if CPU_BIG_ENDIAN
+
 source "arch/powerpc/kvm/Kconfig"
 
 source "kernel/livepatch/Kconfig"

---
base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
change-id: 20251222-cc-can-link-powerpc-5ddd2469fd5b

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

Re: [PATCH] powerpc: Implement ARCH_HAS_CC_CAN_LINK

[Christophe Leroy (CS GROUP)]

Le 30/12/2025 à 08:06, Thomas Weißschuh a écrit :
> 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.

Isn't the kernel supposed to handle any userland endianess ? Macro 
SET_ENDIAN() is there for that as far as I understand.

And if you want to be complete, I think you should also check whether 
the ELF ABI is v1 or v2.

Christophe

> 
> 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 9537a61ebae0..6bb2f90e97ea 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
> @@ -1342,6 +1343,20 @@ endif
>   config PPC_LIB_RHEAP
>   	bool
>   
> +config ARCH_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,$(m32-flag) -mlittle-endian) if CPU_LITTLE_ENDIAN
> +	default $(cc_can_link_user,$(m32-flag) -mbig-endian) if CPU_BIG_ENDIAN
> +
> +config ARCH_USERFLAGS
> +	string
> +	default "$(m64-flag) -mlittle-endian" if 64BIT && CPU_LITTLE_ENDIAN
> +	default "$(m64-flag) -mbig-endian" if 64BIT && CPU_BIG_ENDIAN
> +	default "$(m32-flag) -mlittle-endian" if CPU_LITTLE_ENDIAN
> +	default "$(m32-flag) -mbig-endian" if CPU_BIG_ENDIAN
> +
>   source "arch/powerpc/kvm/Kconfig"
>   
>   source "kernel/livepatch/Kconfig"
> 
> ---
> base-commit: 8f0b4cce4481fb22653697cced8d0d04027cb1e8
> change-id: 20251222-cc-can-link-powerpc-5ddd2469fd5b
> 
> Best regards,

Re: [PATCH] powerpc: Implement ARCH_HAS_CC_CAN_LINK

[Segher Boessenkool]

Hi!

On Sat, Jan 03, 2026 at 11:39:12AM +0100, Christophe Leroy (CS GROUP) wrote:
> Le 30/12/2025 à 08:06, Thomas Weißschuh a écrit :
> > 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.
> 
> Isn't the kernel supposed to handle any userland endianess ? Macro
> SET_ENDIAN() is there for that as far as I understand.

Yes, the kernel does not get much data out of data structures in memory
in the first place :-)

> And if you want to be complete, I think you should also check whether the
> ELF ABI is v1 or v2.

ELFv2 is version 1 of ELF, as wel as version 1 of its particular ABI.
It is just a cutesy name.  The thing now called "ELFv1" was called
"PowerOpen", or simply "PowerPC 64-bit ELF", or one of a hundred other
names :-)

All of the ABIs we use with PowerPC (in trunk, anyway) work with either
endianness (well, you need a userland built for it of course, and maybe
AIX and/or Darwin have not actually been designed to work with wrong-
endian as well).

But powerpc-{elf,linux} and powerpcle-{elf,linux} work equivalently
well, and so do both BE and LE versions of ELFv2 (yes, BE of that exists
just as well, and some distros even ship it!)

powerpc64-linux and powerpc64le-linux use different ABIs though (BE
ELFv1 and LE ELFv2, resp.)


Segher

Re: [PATCH] powerpc: Implement ARCH_HAS_CC_CAN_LINK

[Thomas Weißschuh]

Hi!

On Sat, Jan 03, 2026 at 08:06:42AM -0600, Segher Boessenkool wrote:
> On Sat, Jan 03, 2026 at 11:39:12AM +0100, Christophe Leroy (CS GROUP) wrote:
> > Le 30/12/2025 à 08:06, Thomas Weißschuh a écrit :
> > > 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.
> > 
> > Isn't the kernel supposed to handle any userland endianess ? Macro
> > SET_ENDIAN() is there for that as far as I understand.

To be honest I have no idea how switching endianess in the middle of an
application is supposed to work with C applications. Suddenly all of the
UAPI needs different a different byte order, for which I see no support
in the kernel.

A big-endian kernel still does not seem to load a little-endian userspace
executable and instead fails with ENOEXEC. This is the issue I am trying
to address.

> Yes, the kernel does not get much data out of data structures in memory
> in the first place :-)

Except for all of the UAPI :-/

> > And if you want to be complete, I think you should also check whether the
> > ELF ABI is v1 or v2.
> 
> ELFv2 is version 1 of ELF, as wel as version 1 of its particular ABI.
> It is just a cutesy name.  The thing now called "ELFv1" was called
> "PowerOpen", or simply "PowerPC 64-bit ELF", or one of a hundred other
> names :-)
> 
> All of the ABIs we use with PowerPC (in trunk, anyway) work with either
> endianness (well, you need a userland built for it of course, and maybe
> AIX and/or Darwin have not actually been designed to work with wrong-
> endian as well).
> 
> But powerpc-{elf,linux} and powerpcle-{elf,linux} work equivalently
> well, and so do both BE and LE versions of ELFv2 (yes, BE of that exists
> just as well, and some distros even ship it!)

> powerpc64-linux and powerpc64le-linux use different ABIs though (BE
> ELFv1 and LE ELFv2, resp.)

But these are all toolchain considerations, which are fine.
I am trying to make sure that userprogs are actually *runnable* on the
kernel they are being built together with.


Thomas