On Sat, 26 Aug 2023, John Paul Adrian Glaubitz wrote:
On Sat, 2023-08-26 at 09:53 +0100, James Le Cuirot wrote:
...
Not only mold but also most notably the following projects:
- LLVM
- Firebird Database
- OpenJDK
- Various Qt packages
And potentially more in the future, which may be anticipated on the basis
that "those users don't need a stable ABI any more, so let's just ignore
the portability issues in our code and leave the problem to the distros
and toolchain developers".
That is the precedent you would set.
Moreover, why is it that only a few developers have a problem with making
explicit their decisions regarding alignment of shorts? What actual pain
does it cause them to accept a patch to make their struct layouts plain?
It goes against the traditional ABIs, but practically no m68k Linux
binaries are published outside of distributions, so this not a
concern.
It is of concern to some users (though not all, apparently).
We need to break the ABI anyway with time_t going 64-bit, so it makes
sense to do these two things at the same time.
Fully agreed.
If the kernel breaks the ABI, that's a bug, not an excuse. Either you're
okay with proliferation of incompatible binaries and tools or there are
some criteria (yet to be identified AFAIK) which permit this bug.
It's not difficult to foresee fragmentation because it follows from the
manpower shortage. There will always be sufficient manpower to produce a
break that pleases a few. There may never be enough manpower to produce a
stable ABI that pleases everyone for the foreseeable future.
I think -gnu32 sounds very reasonable.
You do? I think 32 is misleading in the absence of 16-bit or 64-bit
variants, and -gnu is misleading if other tooling like LLVM already
supports malign-int. Moreover, it's impossible to align to a bit count in
general. Not that you'd want to -- it's actually the natural alignment of
shorts that is at issue, AIUI.
So, for naming purposes, the proposal might be described as either the ABI
du jour (leading to -abi23 for 2023) or the new ABI for ever (leading to
-abin as in -gnuabin32 on MIPS).
If it's the former, perhaps you should not push it upstream. If it's the
latter, perhaps this redesign should seek to address real shortcomings
with the existing ABI, including problems which (for all I know) may have
entirely prevented some people from using it thus far. That is, it should
consider silicon beyond 680x0.
