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

[Richard <richiezid@arcor.de>]

On August 26, 2023 10:51:39 AM UTC, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
>Hi James!
>
>On Sat, 2023-08-26 at 09:53 +0100, James Le Cuirot wrote:
>> I wasn't sure whether to send this to libc-alpha or here. This feels more like
>> a request for help, so I decided to play it safe. :)
>
>I am CC'ing Debian's m68k mailing list and the Linux m68k kernel mailing list
>to make sure we're getting enough exposure.
>
>> The Debian m68k maintainers proposed building their packages with -malign-int
>> last year, aligning to 32-bit instead of 16-bit, which improves compatibility
>> with some projects and should give better performance on 68020+, at the cost
>> of slightly increased memory usage. The mold linker is at least one project
>> that has been shown to work after making this change where it previously
>> didn't.
>
>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.

>- LLVM

Ok .. too big to complain about.. and see above.

>- OpenJDK

OpenJDK has not only that one problem.

>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?


>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?

Richard