[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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/87y3i442w1.fsf@linux-m68k.org/.
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/


Reply to: