Re: Tuple and changes for m68k with -malign-int

[Finn Thain <fthain@linux-m68k.org>]

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.