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

[John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>]

On Sat, 2023-08-26 at 19:24 +0000, Richard wrote:
> > Not only mold but also most notably the following projects:
> 
> a linker that is broken by a slightly unusual alignment isn't exactly a
> prime example.. if any project I would expect linkers and binary tools
> to pay attention to portability.

Portable shouldn't mean having to accommodate for unreasonable design decisions
of other developers. It's perfectly fine to assume 32-bit natural alignment on
a 32-bit platform and I don't think it's fair to put the burden of adopting for
unusual design decisions on to upstream projects.

This kind of attitude was certainly one of the reasons why the Itanium architecture
failed. Its designers made weird decisions which made life hard for upstream developers
and most of them were happy when the architecture was finally abandoned.

> > - LLVM
> 
> Ok .. too big to complain about.. and see above.

It's also nearly impossible to make LLVM work with 16-bit alignment because the code uses
certainly packed data types which require 32-bit alignment or higher.

> > - OpenJDK
> 
> OpenJDK has not only that one problem.

That's an unnecessary remark that is not helpful here. Please don't do that!

> > It's a regular occurrence that a package doesn't build on m68k due to it's unusual
> > default alignment. 
> 
> Unfortunately. Some time ago m68k was not the only one with this problem?

Well, as mentioned above, other architectures with weird requirements such as Itanium
have been abandoned and most upstream projects were happy when this finally happened.

> > Thus, in order to keep the port alive in the future, I think
> > switching to 32-bit alignment by default is inevitable.
> > 
> 
> Ok. 
> 
> 
> > > 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.
> 
> 
> What exactly will be broken? Afaics kernel ABIs have been since long pretty carefully
> designed to avoid this problems and noone of the mentioned examples should touch them anyway. 
> 
> Thus.. is there any need to change the kernel ABI?

I don't think this mandates changes to the kernel ABI.

Adrian

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