Re: Can we drop upstream Linux x32 support?

On Tue, Dec 11, 2018 at 09:59:48PM +0000, Thorsten Glaser wrote:

John Paul Adrian Glaubitz dixit:

quoted

I can't say anything about the syscall interface. However, what I do know
is that the weird combination of a 32-bit userland with a 64-bit kernel
interface is sometimes causing issues. For example, application code usually

Yes, but more and more ${foo}64ilp32 architectures are popping up.

quoted

Additionally, x32 support in many applications is either rudimentary

If a signal is sent that this kind of architectures will stay, some
people might be convinced to fix that.

quoted

It's also that the performance benefits of x32 are often eaten up by
the fact that none of the scripted languages that I know of provide

Non-JITted languages like yours truly’s shell do benefit from it,
though. (mksh works just fine on LP64 but its internal structures
pack massively better on ILP32, for example.)

gcc also benefits massively, up to 2x or more performance improvement
from ILP32, just because you can double your -jN to make. The "or
more" comes from cache utilization also improving. Actually I often
use i486 gcc even on 64-bit systems for this reason, and have observed
this order of improvement despite the lack of registers and worse call
ABI. Presumably x32 would be better, but I've avoided it because of
how buggy it's been in the past.

quoted

If x32 is eventually to be removed, we should also take care of removing
x32 support from userland code. From the top of my head, this would at least

I don’t think so. The patches also contain
– stuff to support 64-bit time_t on 32-bit architectures, e.g:
- bugfixes like printf("%lld", (long long)timet_value) instead
  of assuming time_t fits into a long (also important for other
  operating systems…)
- generally switching from generic types like long to specific
  types like size_t, ptrdiff_t, etc.
- there was one more but after having written two eMails I forgot it
- oh and, of course, they lay the base for e.g. amd64ilp32 support

I would not classify any of that as part of "removing x32 support",
but rather as "reintroducing broken assumptions". I think "removing
x32 support" was intended to mean places where there's
explicitly-x32-specific code or tooling, like asm functions/fragments
in libc, x32 versions of the dispatch asm in mesa, x32 code
generation, etc. Obviously (at least I hope it's obvious) nonportable
assumptions should not be reintroduced regardless of whether x32 is
dropped.

FWIW x32 is nice as a test case for catching such nonportable
assumptions and getting them fixed.

Rich