Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

Just curious; does not Linux use the processor-specific flagging in the 
binary that can tell whether it's 16- or 32-bit-aligned (and handle it 
thereafter)?

NetBSD changed VAX from 1k to 4k pages quite some time ago, and to be 
able to use both we added a new id for 4k pages.

-- R

Den 2025-06-05 kl. 09:36, skrev John Paul Adrian Glaubitz:
> Hello Geert,
>
> On Thu, 2025-06-05 at 09:16 +0200, Geert Uytterhoeven wrote:
>>> Yes, please send a patch. I don't expect it to be accepted immediately, but
>>> it will help us spur a discussion on the necessary changes in the kernel.
>> It will be NAKed, because it would break the ABI.
> No problem. We'll carry the patches downstream then. I'm not going to change
> my mind about this because the alternative would be to just let the port die.
>
>> Thank you for providing solid evidence that changing the default
>> alignment in the compiler will break the ABI, and is thus unacceptable.
> And who cares about breaking the ABI in a retro-computing platform except
> for the few people actively maintaining it? This argument only really makes
> sense when talking about something that has commercial relevance or a relevant
> user base.
>
>> (I wanted to test-compile all uapi headers to find differences, but
>> ran into many headers not being self-contained, or causing conflicts).
>>
>> Feel free to start arch/m68k32/ to work around this ;-)
> Nope, we're just going to carry patches downstream and I'll just ignore people
> that actively want to obstruct fixing a long-time problem on m68k with the weak
> argument that it would break Linux binaries from 1993 running on a modern kernel.
>
> This isn't a use case I care about.
>
>> BTW, looking into the history of __ADDR_BND_PKEY_PAD() (which is
>> overkill on m68k, as __alignof__(void *) = 2, but might still be useful
>> for anyone wanting to revive CRIS support ;-), I ran into Andreas'
>> explanation why the minimal alignment is still 2 bytes:
>> https://lore.kernel.org/all/[email protected]/.
> This post just proves that it's always a bad idea to keep historical burden
> instead of fixing it.
>
> Again, can you please bring up a convincing argument why it would be a hard
> problem to break the ABI for Linux on 40-year-old hardware? And who would be
> affected by it?
>
> The ABI isn't set in stone and if need to break it to fix fundamental problems,
> then be it. They even broke the ABI on a production architecture (s390) back
> in 2014 [1] and apparently we were all able to move on after this.
>
> Adrian
>
>> [1] https://lwn.net/Articles/605607/