[PATCH] x86: Start removing X86_X32_ABI

[PATCH] x86: Start removing X86_X32_ABI

[Sebastian Andrzej Siewior]

The x32 ABI was introduced in v3.4 to leverage the additional registers
which were available on x86_64 but not on i386 while keeping the smaller
32bit pointers.

This did not take off. The memory usage usually knows no limit and the
better performance did not reach a point where certain workloads widely
move to x32 and use it exclusively. In the meantime Debian introduced a
patch to disable x32 by default (so it has to be enabled at boot time on
the command line) because they are afraid of the increased attack
surface. Fedora as far as I tell has X32 disabled (looking at 7.0-rc5
rpm in rawhide).

The last syscall for x86_64 is currently at 471. The first x32 starts at
512 which leaves 40 new syscalls in between. Without the x32 ABI, those
syscalls could be used since x32 wouldn't be an option and therefore
reserved.

Since there is practically no real use for x32, start removing it by
removing the symbol first, not allowing to enable it. Should nothing
happening within the next half year, lets remove code bits around August
after the summer break.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
 arch/x86/Kconfig | 14 --------------
 1 file changed, 14 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f3f7cb01d69d0..2b246a6125768 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -3143,20 +3143,6 @@ config IA32_EMULATION_DEFAULT_DISABLED
 	  processes and access to 32-bit syscalls. If unsure, leave it to its
 	  default value.
 
-config X86_X32_ABI
-	bool "x32 ABI for 64-bit mode"
-	depends on X86_64
-	# llvm-objcopy does not convert x86_64 .note.gnu.property or
-	# compressed debug sections to x86_x32 properly:
-	# https://github.com/ClangBuiltLinux/linux/issues/514
-	# https://github.com/ClangBuiltLinux/linux/issues/1141
-	depends on $(success,$(OBJCOPY) --version | head -n1 | grep -qv llvm)
-	help
-	  Include code to run binaries for the x32 native 32-bit ABI
-	  for 64-bit processors.  An x32 process gets access to the
-	  full 64-bit register file and wide data path while leaving
-	  pointers at 32 bits for smaller memory footprint.
-
 config COMPAT_32
 	def_bool y
 	depends on IA32_EMULATION || X86_32
-- 
2.53.0

Re: [PATCH] x86: Start removing X86_X32_ABI

[H. Peter Anvin]

On May 23, 2026 2:37:34 AM PDT, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>The x32 ABI was introduced in v3.4 to leverage the additional registers
>which were available on x86_64 but not on i386 while keeping the smaller
>32bit pointers.
>
>This did not take off. The memory usage usually knows no limit and the
>better performance did not reach a point where certain workloads widely
>move to x32 and use it exclusively. In the meantime Debian introduced a
>patch to disable x32 by default (so it has to be enabled at boot time on
>the command line) because they are afraid of the increased attack
>surface. Fedora as far as I tell has X32 disabled (looking at 7.0-rc5
>rpm in rawhide).
>
>The last syscall for x86_64 is currently at 471. The first x32 starts at
>512 which leaves 40 new syscalls in between. Without the x32 ABI, those
>syscalls could be used since x32 wouldn't be an option and therefore
>reserved.
>
>Since there is practically no real use for x32, start removing it by
>removing the symbol first, not allowing to enable it. Should nothing
>happening within the next half year, lets remove code bits around August
>after the summer break.
>
>Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
>---
> arch/x86/Kconfig | 14 --------------
> 1 file changed, 14 deletions(-)
>
>diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>index f3f7cb01d69d0..2b246a6125768 100644
>--- a/arch/x86/Kconfig
>+++ b/arch/x86/Kconfig
>@@ -3143,20 +3143,6 @@ config IA32_EMULATION_DEFAULT_DISABLED
> 	  processes and access to 32-bit syscalls. If unsure, leave it to its
> 	  default value.
> 
>-config X86_X32_ABI
>-	bool "x32 ABI for 64-bit mode"
>-	depends on X86_64
>-	# llvm-objcopy does not convert x86_64 .note.gnu.property or
>-	# compressed debug sections to x86_x32 properly:
>-	# https://github.com/ClangBuiltLinux/linux/issues/514
>-	# https://github.com/ClangBuiltLinux/linux/issues/1141
>-	depends on $(success,$(OBJCOPY) --version | head -n1 | grep -qv llvm)
>-	help
>-	  Include code to run binaries for the x32 native 32-bit ABI
>-	  for 64-bit processors.  An x32 process gets access to the
>-	  full 64-bit register file and wide data path while leaving
>-	  pointers at 32 bits for smaller memory footprint.
>-
> config COMPAT_32
> 	def_bool y
> 	depends on IA32_EMULATION || X86_32

So I'm not opposed to sunsetting x32; it happened too late to actually be able to become useful (sorry, Knuth.)

However, we can not recycle the syscall numbers. The x32 flag in the syscall number was advisory originally; it was introduced late in the game to work around a design bug in the input subsystem (*).

   -hpa

(*) Classic example of taking a binary interface and "translating" it into a text interface, in the process making it worse than either: taking a bitmask and exposing it as a space-separated list unsigned longs in decimal form. 

Re: [PATCH] x86: Start removing X86_X32_ABI

[Sebastian Andrzej Siewior]

On 2026-05-23 14:43:52 [-0700], H. Peter Anvin wrote:
> However, we can not recycle the syscall numbers. The x32 flag in the
> syscall number was advisory originally; it was introduced late in the
> game to work around a design bug in the input subsystem (*).

If x32 is removed/ not supported why can't the 32/64 bit ABI use syscall
numbers 512+? It is an ELF32 with EM_X86_64 which should be rejected.
Shouldn't this free the space because there are no users anymore?

>    -hpa

Sebastian

Re: [PATCH] x86: Start removing X86_X32_ABI

[H. Peter Anvin]

On May 26, 2026 3:40:51 AM PDT, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>On 2026-05-23 14:43:52 [-0700], H. Peter Anvin wrote:
>> However, we can not recycle the syscall numbers. The x32 flag in the
>> syscall number was advisory originally; it was introduced late in the
>> game to work around a design bug in the input subsystem (*).
>
>If x32 is removed/ not supported why can't the 32/64 bit ABI use syscall
>numbers 512+? It is an ELF32 with EM_X86_64 which should be rejected.
>Shouldn't this free the space because there are no users anymore?
>
>>    -hpa
>
>Sebastian

No, because you don't want the same system call number to have different meaning on different kernels, potentially succeed with totally the wrong meaning.

Re: [PATCH] x86: Start removing X86_X32_ABI

[H. Peter Anvin]

On May 26, 2026 3:40:51 AM PDT, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>On 2026-05-23 14:43:52 [-0700], H. Peter Anvin wrote:
>> However, we can not recycle the syscall numbers. The x32 flag in the
>> syscall number was advisory originally; it was introduced late in the
>> game to work around a design bug in the input subsystem (*).
>
>If x32 is removed/ not supported why can't the 32/64 bit ABI use syscall
>numbers 512+? It is an ELF32 with EM_X86_64 which should be rejected.
>Shouldn't this free the space because there are no users anymore?
>
>>    -hpa
>
>Sebastian

System call numbers or even mechanisms are in no wise tied to the ELF type. An x86-64 binary can issue x86-64, x32 or i386 system calls, even from 64-bit mode!

Re: [PATCH] x86: Start removing X86_X32_ABI

[Sebastian Andrzej Siewior]

On 2026-05-26 08:54:56 [-0700], H. Peter Anvin wrote:
> No, because you don't want the same system call number to have
> different meaning on different kernels, potentially succeed with
> totally the wrong meaning.

My point is that if you rip out x32 entirely there is no point in
reversing the syscall numbers since you can't use x32 anyway.

> System call numbers or even mechanisms are in no wise tied to the ELF
> type. An x86-64 binary can issue x86-64, x32 or i386 system calls,
> even from 64-bit mode!

Hmm. Judging from compat_elf_check_arch() it looks like it is
restricted. 

But *why* have syscalls if nothing else works? It is not that you have a
natural environment where these things work and in a later kernel they
behave differently. It just not working.

Sebastian

Re: [PATCH] x86: Start removing X86_X32_ABI

[Arnd Bergmann]

On Tue, May 26, 2026, at 22:43, Sebastian Andrzej Siewior wrote:
> On 2026-05-26 08:54:56 [-0700], H. Peter Anvin wrote:
>
>> System call numbers or even mechanisms are in no wise tied to the ELF
>> type. An x86-64 binary can issue x86-64, x32 or i386 system calls,
>> even from 64-bit mode!
>
> But *why* have syscalls if nothing else works? It is not that you have a
> natural environment where these things work and in a later kernel they
> behave differently. It just not working.

It's not about having the syscalls, it's whether we need to keep
them as 'reserved' indefinitely, the same way we don't reuse
any other number that ever did something.

The problem is what happens when you run new userspace that calls
a syscall >512 on a kernel before v5.4 with x32 enabled, see commit
6365b842aae4 ("x86/syscalls: Split the x32 syscalls into their own
table").

The normal rule is that any new syscall should return -ENOSYS on
old kernels to make it safe to detect from userspace whether it
is available or not. On linux-5.4 or newer kernels, that is what
happens. On older ones this would call one of the 35 x32 syscalls
that were available at the time. 

Skipping these numbers is clearly annoying, given that we now
synchronize them across all architectures, but it's probably
the right thing to do, at least if C libraries that want to
support future syscalls >511 also want to keep running on old
kernels. glibc still officially supports linux-3.2 (2.6.32
on x86), and musl tries to support even older versions.

      Arnd

Re: [PATCH] x86: Start removing X86_X32_ABI

[Sebastian Andrzej Siewior]

On 2026-05-31 23:46:10 [+0200], Arnd Bergmann wrote:
> On Tue, May 26, 2026, at 22:43, Sebastian Andrzej Siewior wrote:
> > On 2026-05-26 08:54:56 [-0700], H. Peter Anvin wrote:
> >
> >> System call numbers or even mechanisms are in no wise tied to the ELF
> >> type. An x86-64 binary can issue x86-64, x32 or i386 system calls,
> >> even from 64-bit mode!
> >
> > But *why* have syscalls if nothing else works? It is not that you have a
> > natural environment where these things work and in a later kernel they
> > behave differently. It just not working.
> 
> It's not about having the syscalls, it's whether we need to keep
> them as 'reserved' indefinitely, the same way we don't reuse
> any other number that ever did something.
> 
> The problem is what happens when you run new userspace that calls
> a syscall >512 on a kernel before v5.4 with x32 enabled, see commit
> 6365b842aae4 ("x86/syscalls: Split the x32 syscalls into their own
> table").

Okay, that is point. That would be something like new Debian distro but
still the old kernel.

> The normal rule is that any new syscall should return -ENOSYS on
> old kernels to make it safe to detect from userspace whether it
> is available or not. On linux-5.4 or newer kernels, that is what
> happens. On older ones this would call one of the 35 x32 syscalls
> that were available at the time. 
> 
> Skipping these numbers is clearly annoying, given that we now
> synchronize them across all architectures, but it's probably
> the right thing to do, at least if C libraries that want to
> support future syscalls >511 also want to keep running on old
> kernels. glibc still officially supports linux-3.2 (2.6.32
> on x86), and musl tries to support even older versions.

I see. That is unfortunate then.

But just to check one thing: From the referenced commit "ioctl() is nr
16 on x86_64 but 514 on x32". So the kernel knows if it is x-64 or x-32?
But we can't reuse 514 on x-64 and return -1 on -x32 simply because the
pre v5.4 kernel do the ioctl() instead of an error?

>       Arnd

Sebastian

Re: [PATCH] x86: Start removing X86_X32_ABI

[Arnd Bergmann]

On Mon, Jun 1, 2026, at 23:44, Sebastian Andrzej Siewior wrote:
> On 2026-05-31 23:46:10 [+0200], Arnd Bergmann wrote:
>>
>> The problem is what happens when you run new userspace that calls
>> a syscall >512 on a kernel before v5.4 with x32 enabled, see commit
>> 6365b842aae4 ("x86/syscalls: Split the x32 syscalls into their own
>> table").
>
> Okay, that is point. That would be something like new Debian distro but
> still the old kernel.

Right, or maybe even more common an embedded system running an
old kernel that a SoC vendor has never updated, but using a recent
musl build.

>> Skipping these numbers is clearly annoying, given that we now
>> synchronize them across all architectures, but it's probably
>> the right thing to do, at least if C libraries that want to
>> support future syscalls >511 also want to keep running on old
>> kernels. glibc still officially supports linux-3.2 (2.6.32
>> on x86), and musl tries to support even older versions.
>
> I see. That is unfortunate then.
>
> But just to check one thing: From the referenced commit "ioctl() is nr
> 16 on x86_64 but 514 on x32". So the kernel knows if it is x-64 or x-32?
> But we can't reuse 514 on x-64 and return -1 on -x32 simply because the
> pre v5.4 kernel do the ioctl() instead of an error?

The kernel only sees a 32-bit number, with bit 30 (0x40000000)
set by libc in regular x32 user space, so x32 ioctl() would be
1073742338 (0x40000202). On newer kernels, the bit gets checked
in do_syscall_64() so it has to be cleared for LP64-only
syscalls but set for ILP32-only ones.

Before 6365b842aae4, the bit was just masked out, so it made
no difference for deciding if a syscall was valid and
was only checked in in_x32_syscall().

On syscalls that are the same between the two, the bit has no
practical effect today.

       Arnd

Re: [PATCH] x86: Start removing X86_X32_ABI

[David Laight]

On Tue, 26 May 2026 08:54:56 -0700
"H. Peter Anvin" <hpa@zytor.com> wrote:

> On May 26, 2026 3:40:51 AM PDT, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
> >On 2026-05-23 14:43:52 [-0700], H. Peter Anvin wrote:  
> >> However, we can not recycle the syscall numbers. The x32 flag in the
> >> syscall number was advisory originally; it was introduced late in the
> >> game to work around a design bug in the input subsystem (*).  
> >
> >If x32 is removed/ not supported why can't the 32/64 bit ABI use syscall
> >numbers 512+? It is an ELF32 with EM_X86_64 which should be rejected.
> >Shouldn't this free the space because there are no users anymore?
> >  
> >>    -hpa  
> >
> >Sebastian  
> 
> System call numbers or even mechanisms are in no wise tied to the ELF type.
> An x86-64 binary can issue x86-64, x32 or i386 system calls, even from 64-bit mode! 
> 

I suspect a 32bit binary can also switch to 64bit mode and issue any
of them as well.

-- David

Re: [PATCH] x86: Start removing X86_X32_ABI

[H. Peter Anvin]

On May 27, 2026 5:02:04 AM PDT, David Laight <david.laight.linux@gmail.com> wrote:
>On Tue, 26 May 2026 08:54:56 -0700
>"H. Peter Anvin" <hpa@zytor.com> wrote:
>
>> On May 26, 2026 3:40:51 AM PDT, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>> >On 2026-05-23 14:43:52 [-0700], H. Peter Anvin wrote:  
>> >> However, we can not recycle the syscall numbers. The x32 flag in the
>> >> syscall number was advisory originally; it was introduced late in the
>> >> game to work around a design bug in the input subsystem (*).  
>> >
>> >If x32 is removed/ not supported why can't the 32/64 bit ABI use syscall
>> >numbers 512+? It is an ELF32 with EM_X86_64 which should be rejected.
>> >Shouldn't this free the space because there are no users anymore?
>> >  
>> >>    -hpa  
>> >
>> >Sebastian  
>> 
>> System call numbers or even mechanisms are in no wise tied to the ELF type.
>> An x86-64 binary can issue x86-64, x32 or i386 system calls, even from 64-bit mode! 
>> 
>
>I suspect a 32bit binary can also switch to 64bit mode and issue any
>of them as well.
>
>-- David

Yes, they can. But you don't even need to switch to 32-bit mode to issue an i386 syscall.

Re: [PATCH] x86: Start removing X86_X32_ABI

[Thomas Gleixner]

On Sat, May 23 2026 at 14:43, H. Peter Anvin wrote:
> On May 23, 2026 2:37:34 AM PDT, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>>-
>> config COMPAT_32
>> 	def_bool y
>> 	depends on IA32_EMULATION || X86_32
>
> So I'm not opposed to sunsetting x32; it happened too late to actually
> be able to become useful (sorry, Knuth.)

I doubt it was ever useful, but that's a different debate to be had.

> However, we can not recycle the syscall numbers. The x32 flag in the
> syscall number was advisory originally; it was introduced late in the
> game to work around a design bug in the input subsystem (*).

Correct. That's unfortunate and basically forces us to skip the
arbitrary x32 range for all architectures if we want to keep the syscall
numbers in sync.

But aside of that x32 is just another maintenance burden for no value.

Please let us get rid of it and document that the syscall number space
is poisened forever.

Thanks,

        tglx

Re: [PATCH] x86: Start removing X86_X32_ABI

[Sam James]

[-- Attachment #1: Type: text/plain, Size: 262 bytes --]

I'm not going to claim it's a popular platform but we do have some
actual users on it who pop up every so often when they hit a bug, but
the kind of people who use it are often quite content to fix things
themselves locally.

It also works reasonably well.

sam

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 418 bytes --]

Re: [PATCH] x86: Start removing X86_X32_ABI

[Neal Gompa]

On Saturday, May 23, 2026 5:37:34 AM Eastern Daylight Time Sebastian Andrzej 
Siewior wrote:
> The x32 ABI was introduced in v3.4 to leverage the additional registers
> which were available on x86_64 but not on i386 while keeping the smaller
> 32bit pointers.
> 
> This did not take off. The memory usage usually knows no limit and the
> better performance did not reach a point where certain workloads widely
> move to x32 and use it exclusively. In the meantime Debian introduced a
> patch to disable x32 by default (so it has to be enabled at boot time on
> the command line) because they are afraid of the increased attack
> surface. Fedora as far as I tell has X32 disabled (looking at 7.0-rc5
> rpm in rawhide).
> 
> The last syscall for x86_64 is currently at 471. The first x32 starts at
> 512 which leaves 40 new syscalls in between. Without the x32 ABI, those
> syscalls could be used since x32 wouldn't be an option and therefore
> reserved.
> 
> Since there is practically no real use for x32, start removing it by
> removing the symbol first, not allowing to enable it. Should nothing
> happening within the next half year, lets remove code bits around August
> after the summer break.
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---

I'm not saying that there's a lot of users, and it may still be worth 
eliminating it, but PLD Linux has actively supported x86_64 with x32 ABI for 
well over a decade now. They maintain a patchset on RPM to expose this 
properly (and I've attempted to create better versions for upstreaming[1][2], 
and there was a third attempt[3] too).

So it isn't broadly used indeed, but it's used enough that it's probably worth 
being slightly more careful about deciding to remove it.

[1]: https://github.com/rpm-software-management/rpm/pull/360
[2]: https://github.com/rpm-software-management/rpm/pull/1038
[3]: https://github.com/rpm-software-management/rpm/pull/3578


-- 
真実はいつも一つ！/ Always, there's only one truth!

Re: [PATCH] x86: Start removing X86_X32_ABI

[John Paul Adrian Glaubitz]

Hello Sebastian,

On Sat, 2026-05-23 at 11:37 +0200, Sebastian Andrzej Siewior wrote:
> The x32 ABI was introduced in v3.4 to leverage the additional registers
> which were available on x86_64 but not on i386 while keeping the smaller
> 32bit pointers.
> 
> This did not take off. The memory usage usually knows no limit and the
> better performance did not reach a point where certain workloads widely
> move to x32 and use it exclusively. In the meantime Debian introduced a
> patch to disable x32 by default (so it has to be enabled at boot time on
> the command line) because they are afraid of the increased attack
> surface. Fedora as far as I tell has X32 disabled (looking at 7.0-rc5
> rpm in rawhide).
> 
> The last syscall for x86_64 is currently at 471. The first x32 starts at
> 512 which leaves 40 new syscalls in between. Without the x32 ABI, those
> syscalls could be used since x32 wouldn't be an option and therefore
> reserved.
> 
> Since there is practically no real use for x32, start removing it by
> removing the symbol first, not allowing to enable it. Should nothing
> happening within the next half year, lets remove code bits around August
> after the summer break.

Debian still has an x32 port which is building unstable packages, see [1].

Even Rust works there.

Adrian

> [1] https://buildd.debian.org/status/architecture.php?a=x32&suite=sid

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] x86: Start removing X86_X32_ABI

[Sebastian Andrzej Siewior]

On 2026-05-27 17:57:30 [+0200], John Paul Adrian Glaubitz wrote:
> Hello Sebastian,
Hi Adrian,

> Debian still has an x32 port which is building unstable packages, see [1].

I am aware that Debian has this. 

> Even Rust works there.

Even rust. You have approx. ~72% of packages
	https://buildd.debian.org/stats/graph-ports-week-big.png

and peaked at ~90% in 2016 and then again shortly before 2022
	https://buildd.debian.org/stats/graph-ports-big.png

Some of the big ones are missing like libreoffice, firefox or chromium.

In 2012 x32 was introduced. Around 2013 if I am not mistaken x32 entered
d-ports. This is where we still are. That is why I think it is time to
let it rest.

Debian Squeeze and Wheezy had kfreebsd as a tech-preview, sadly not
more. 

> 
> Adrian

Sebastian

Re: [PATCH] x86: Start removing X86_X32_ABI

[H. Peter Anvin]

On June 1, 2026 2:12:09 PM PDT, Sebastian Andrzej Siewior <bigeasy@linutronix.de> wrote:
>On 2026-05-27 17:57:30 [+0200], John Paul Adrian Glaubitz wrote:
>> Hello Sebastian,
>Hi Adrian,
>
>> Debian still has an x32 port which is building unstable packages, see [1].
>
>I am aware that Debian has this. 
>
>> Even Rust works there.
>
>Even rust. You have approx. ~72% of packages
>	https://buildd.debian.org/stats/graph-ports-week-big.png
>
>and peaked at ~90% in 2016 and then again shortly before 2022
>	https://buildd.debian.org/stats/graph-ports-big.png
>
>Some of the big ones are missing like libreoffice, firefox or chromium.
>
>In 2012 x32 was introduced. Around 2013 if I am not mistaken x32 entered
>d-ports. This is where we still are. That is why I think it is time to
>let it rest.
>
>Debian Squeeze and Wheezy had kfreebsd as a tech-preview, sadly not
>more. 
>
>> 
>> Adrian
>
>Sebastian

If someone cares about x32 today it is going to be a user who owns the whole stack, either on servers (with many processes) or embedded.

Re: [PATCH] x86: Start removing X86_X32_ABI

[Tomas Glozar]

FWIW, T2 Linux [1] also has an option to build x32, and there have been such
builds last year [2]. Since this year, it switched to building KDE Plasma
desktop ISOs, where x32 makes less sense, though, as modern desktop is rather
RAM-hungry.

[1] https://t2linux.com
[2] https://dl.t2sde.org/binary/2025/t2-25.10-x32-base-wayland-glibc-gcc-nocona.iso

Also at least 6 years ago, x32 was reported there to increase performance by
some 5-8% [3] likely thanks to smaller pointers allowing better cache
utilization. That is not insignificant, and not all tasks require gigabytes of
RAM (e.g. compression and encryption, as shown in the link).

[3] https://www.youtube.com/live/Mw-ravkg67k?si=HS7ZHZyg_FKXPZUz&t=387 (yeah
YouTube video not the best source...)

Tomas

Re: [PATCH] x86: Start removing X86_X32_ABI

[Sebastian Andrzej Siewior]

On 2026-05-28 09:05:48 [+0200], Tomas Glozar wrote:
> FWIW, T2 Linux [1] also has an option to build x32, and there have been such
> builds last year [2]. Since this year, it switched to building KDE Plasma
> desktop ISOs, where x32 makes less sense, though, as modern desktop is rather
> RAM-hungry.

I wasn't aware of this. If an application, such as chromium, is memory
hungry the x32 doesn't help much to contain it. Your pointer are
smaller, granted, but the overall memory consumption is still
significant. Running x32 means also that a single application is not
able to use more than 4GiB or memory.

> [1] https://t2linux.com
> [2] https://dl.t2sde.org/binary/2025/t2-25.10-x32-base-wayland-glibc-gcc-nocona.iso
> 
> Also at least 6 years ago, x32 was reported there to increase performance by
> some 5-8% [3] likely thanks to smaller pointers allowing better cache
> utilization. That is not insignificant, and not all tasks require gigabytes of
> RAM (e.g. compression and encryption, as shown in the link).

Arnd told me quite some time ago that cross compiling (or compiling in
general) has better performance on x32 than x86-64. This was the only
case afaik. 

> [3] https://www.youtube.com/live/Mw-ravkg67k?si=HS7ZHZyg_FKXPZUz&t=387 (yeah
> YouTube video not the best source...)

So from that linked video, there few cases where x32 builds quicker. But
then at 9.51 there is runtime x64-O2 is leading. The video is titled
5%-8% but I don't see where this is from.

> Tomas

Sebastian

Re: [PATCH] x86: Start removing X86_X32_ABI

[Arnd Bergmann]

On Sat, May 23, 2026, at 11:37, Sebastian Andrzej Siewior wrote:
>
> The last syscall for x86_64 is currently at 471. The first x32 starts at
> 512 which leaves 40 new syscalls in between. Without the x32 ABI, those
> syscalls could be used since x32 wouldn't be an option and therefore
> reserved.
>
> Since there is practically no real use for x32, start removing it by
> removing the symbol first, not allowing to enable it. Should nothing
> happening within the next half year, lets remove code bits around August
> after the summer break.
>
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>

I think the main reason to remove x32 support is all the special
cases we have for it where it is different from normal 'compat'
syscall and ioctl handling, which leaks all the way into file
systems and device drivers (sound/core/pcm_compat.c,
fs/fuse/ioctl.c, fs/read_write, ...) as well as user space
trying to handle 64-bit time_t in a portable way.

I agree removing the Kconfig symbol (or marking it as 'depends
on BROKEN' as we did for arm64 big-endian mode) is a good
idea at this time, but I think the timing for removing the
actual implementation should allow the next LTS kernel (7.4?)
to be released with the current level of support still present.

        Arnd

Re: [PATCH] x86: Start removing X86_X32_ABI

[Maciej W. Rozycki]

On Mon, 1 Jun 2026, Arnd Bergmann wrote:

> I think the main reason to remove x32 support is all the special
> cases we have for it where it is different from normal 'compat'
> syscall and ioctl handling, which leaks all the way into file
> systems and device drivers (sound/core/pcm_compat.c,
> fs/fuse/ioctl.c, fs/read_write, ...) as well as user space
> trying to handle 64-bit time_t in a portable way.

 FWIW it's no different from n32 MIPS ABI support, which we've had for 
even longer and isn't going away anytime soon.  So there's undoubtedly 
some x86-specific stuff there, but generic support for an ILP32 ABI is 
there to stay both in the kernel and on the user side.

  Maciej

Re: [PATCH] x86: Start removing X86_X32_ABI

[Arnd Bergmann]

On Tue, Jun 2, 2026, at 18:02, Maciej W. Rozycki wrote:
> On Mon, 1 Jun 2026, Arnd Bergmann wrote:
>
>> I think the main reason to remove x32 support is all the special
>> cases we have for it where it is different from normal 'compat'
>> syscall and ioctl handling, which leaks all the way into file
>> systems and device drivers (sound/core/pcm_compat.c,
>> fs/fuse/ioctl.c, fs/read_write, ...) as well as user space
>> trying to handle 64-bit time_t in a portable way.
>
>  FWIW it's no different from n32 MIPS ABI support, which we've had for 
> even longer and isn't going away anytime soon.  So there's undoubtedly 
> some x86-specific stuff there, but generic support for an ILP32 ABI is 
> there to stay both in the kernel and on the user side.

For the parts I'm interested in, it's a huge difference: MIPS o32
and n32 have essentially the same types and syscalls aside from the
few structures that describe the actual registers (pt_regs, sigcontext)
and the syscall numbers.

On x32, there are custom integer types (__kernel_ulong_t,
__kernel_old_time_t, __kernel_ipc_pid_t, __kernel_uid_t, ...)
and alignment rules that were intended to match the native x86-64
types for simplicity but end up doing the opposite by requiring
compat ioctl handling to be aware of the difference and implement
a third case when the x32 version is different from both the
i386 and the x86-64 one.

Even for the cases where x32 ends up using the same syscall
as x86-64 because of these type choices (e.g. gettimeofday),
this still needs a special case in the kernel because all other
compat architectures have a shared compat version.

      Arnd

Re: [PATCH] x86: Start removing X86_X32_ABI

[H. Peter Anvin]

On June 2, 2026 9:36:54 AM PDT, Arnd Bergmann <arnd@arndb.de> wrote:
>On Tue, Jun 2, 2026, at 18:02, Maciej W. Rozycki wrote:
>> On Mon, 1 Jun 2026, Arnd Bergmann wrote:
>>
>>> I think the main reason to remove x32 support is all the special
>>> cases we have for it where it is different from normal 'compat'
>>> syscall and ioctl handling, which leaks all the way into file
>>> systems and device drivers (sound/core/pcm_compat.c,
>>> fs/fuse/ioctl.c, fs/read_write, ...) as well as user space
>>> trying to handle 64-bit time_t in a portable way.
>>
>>  FWIW it's no different from n32 MIPS ABI support, which we've had for 
>> even longer and isn't going away anytime soon.  So there's undoubtedly 
>> some x86-specific stuff there, but generic support for an ILP32 ABI is 
>> there to stay both in the kernel and on the user side.
>
>For the parts I'm interested in, it's a huge difference: MIPS o32
>and n32 have essentially the same types and syscalls aside from the
>few structures that describe the actual registers (pt_regs, sigcontext)
>and the syscall numbers.
>
>On x32, there are custom integer types (__kernel_ulong_t,
>__kernel_old_time_t, __kernel_ipc_pid_t, __kernel_uid_t, ...)
>and alignment rules that were intended to match the native x86-64
>types for simplicity but end up doing the opposite by requiring
>compat ioctl handling to be aware of the difference and implement
>a third case when the x32 version is different from both the
>i386 and the x86-64 one.
>
>Even for the cases where x32 ends up using the same syscall
>as x86-64 because of these type choices (e.g. gettimeofday),
>this still needs a special case in the kernel because all other
>compat architectures have a shared compat version.
>
>      Arnd

Yes, and that was the original intent for x86-x32 as well, with the idea being to let the various 32-bit APIs catch up at their own pace. 

Linus vetoed that.

Re: [PATCH] x86: Start removing X86_X32_ABI

[Richard Purdie]

On Sat, 2026-05-23 at 11:37 +0200, Sebastian Andrzej Siewior wrote:
> The x32 ABI was introduced in v3.4 to leverage the additional registers
> which were available on x86_64 but not on i386 while keeping the smaller
> 32bit pointers.
> 
> This did not take off. The memory usage usually knows no limit and the
> better performance did not reach a point where certain workloads widely
> move to x32 and use it exclusively. In the meantime Debian introduced a
> patch to disable x32 by default (so it has to be enabled at boot time on
> the command line) because they are afraid of the increased attack
> surface. Fedora as far as I tell has X32 disabled (looking at 7.0-rc5
> rpm in rawhide).
> 
> The last syscall for x86_64 is currently at 471. The first x32 starts at
> 512 which leaves 40 new syscalls in between. Without the x32 ABI, those
> syscalls could be used since x32 wouldn't be an option and therefore
> reserved.
> 
> Since there is practically no real use for x32, start removing it by
> removing the symbol first, not allowing to enable it. Should nothing
> happening within the next half year, lets remove code bits around August
> after the summer break.
> 
> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
> ---
>  arch/x86/Kconfig | 14 --------------
>  1 file changed, 14 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index f3f7cb01d69d0..2b246a6125768 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -3143,20 +3143,6 @@ config IA32_EMULATION_DEFAULT_DISABLED
>  	  processes and access to 32-bit syscalls. If unsure, leave it to its
>  	  default value.
>  
> -config X86_X32_ABI
> -	bool "x32 ABI for 64-bit mode"
> -	depends on X86_64
> -	# llvm-objcopy does not convert x86_64 .note.gnu.property or
> -	# compressed debug sections to x86_x32 properly:
> -	# https://github.com/ClangBuiltLinux/linux/issues/514
> -	# https://github.com/ClangBuiltLinux/linux/issues/1141
> -	depends on $(success,$(OBJCOPY) --version | head -n1 | grep -qv llvm)
> -	help
> -	  Include code to run binaries for the x32 native 32-bit ABI
> -	  for 64-bit processors.  An x32 process gets access to the
> -	  full 64-bit register file and wide data path while leaving
> -	  pointers at 32 bits for smaller memory footprint.
> -
>  config COMPAT_32
>  	def_bool y
>  	depends on IA32_EMULATION || X86_32

FWIW we (as in the Yocto Project) have been supporting x32 for a long
time so we regularly build/boot/test this as part of our CI (toolchain
+ kernel + userspace). That does mean we end up sending patches when
things break. We did reduce the scope of the userspace we test a few
years ago to try and keep things manageable.

We struggle (as most do) to know who uses what, nobody tells us when it
works. My instincts say it isn't actively used and if the kernel drops
it, we would follow. I don't have any strong objection at this point. I
mention it mainly to explain why you might see patches from us.

Cheers,

Richard