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

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

[John Paul Adrian Glaubitz]

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:

- LLVM
- Firebird Database
- OpenJDK
- Various Qt packages

It's a regular occurrence that a package doesn't build on m68k due to it's unusual
default alignment. Thus, in order to keep the port alive in the future, I think
switching to 32-bit alignment by default is inevitable.

> It goes against the traditional ABIs, but practically no m68k Linux binaries
> are published outside of distributions, so this not a concern. 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.

> We in Gentoo fully support this idea. We had hoped that Debian would take the
> initiative, but we're not aware of any movement yet, and we're keen to make
> this transition, so I'm here to get the ball rolling.

We haven't had a larger discussion yet and I didn't want to impose any changes
before we have agreed on how to move forward. Thanks a lot for finally starting
the discussion.

> We think this warrants a new tuple, and we'd like to ensure that everyone gets
> behind the same one. It is currently m68k-*-gnu. Perhaps it could be
> m68k-*-gnu32 or m68k-*-gnu32a? I considered gnu32i (for int), but the flag
> actually affects floats and doubles too. I don't really care what it is
> though, so feel free to suggest something totally different.

I think -gnu32 sounds very reasonable. I'm actually also wondering what is being
used for other ports that are going to be rebuilt with 64-bit time_t. Maybe we
could use that naming scheme. I guess using "gnu32" for any 32-bit port with
64-bit time_t might not be the obvious choice.

So, while I like the gnu32 suffix, I would suggest we do some research first to find
out what the commonly used triplet change will be used for 32-bit ports switching
to 64-bit time_t.

> Once that is agreed, I'm happy to put together the patch to automatically
> enable the flag for this tuple in GCC. The part I do need help with is
> necessary changes to glibc, if any. Assembly is not my area at all, so what I
> came up with here was a total guess.

Thanks for already looking into the implementation details!

> --- a/sysdeps/m68k/crti.S       2022-07-29 23:03:09.000000000 +0100
> +++ b/sysdeps/m68k/crti.S       2022-11-30 21:41:52.710135230 +0000
> @@ -56,7 +56,7 @@
>  #endif
>  
>         .section .init,"ax",@progbits
> -       .align  2
> +       .p2align        2
>         .globl  _init
>         .hidden _init
>         .type   _init, @function
> @@ -74,7 +74,7 @@
>  #endif
>  
>         .section .fini,"ax",@progbits
> -       .align  2
> +       .p2align        2
>         .globl  _fini
>         .hidden _fini
>         .type   _fini, @function
> 
> 
> I did try this out, and it largely seemed to work, although processes
> occasionally hung. Perhaps this was unrelated.
> 
> It was a while back now and I can't remember if I also built the Linux kernel
> with -malign-int. Does it need to match? Presumably it would at least give the
> same kind of performance benefit?

I cannot comment on this at the moment, so let's wait for the more experienced
m68k kernel and toolchain folks to chime in.

> Thanks for helping to keep m68k alive.

Thank you, too, and thanks for getting this rolling!

Adrian

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

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

[Richard]

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

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

[James Le Cuirot]

On Sat, 2023-08-26 at 19:24 +0000, Richard wrote:
> 
> 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.

Not the best example, I grant you, but it was the only one where I'd
personally witnessed it making a difference so far.

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

Possibly, but I wouldn't know. I suspect it may be the only one still in use
with Linux. Gentoo supports most of the architectures to some degree, and I'm
not aware of any those having this issue.

> 
> > > 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 mentioned the kernel, but I'm not sure whether that's actually affected.
This is more about userland compatibility in the same way that arm-*-gnu,
arm-*-gnueabi, and arm-*gnueabihf are incompatible with each other. I did try
mixing the latter two once. This was swiftly met with a segfault.

Of course, a tuple doesn't stop users from mixing these binaries, but it is a
good way to ensure that GCC enables the flag when appropriate. This is too
important to rely on CFLAGS.

As for time_t, I hadn't realised a different tuple was being proposed for
that, but a fellow Gentoo dev confirms. The breakage here is less severe but
still significant. I witnessed it first-hand on 32-bit ARM when GnuTLS started
using 64-bit time_t while curl was still expecting 32-bit, which lead to HTTPS
requests failing because the certificate start/end dates were completely
wrong. At that point, we realised this is something that needs to be applied
system-wide.

I believe we're still waiting on consensus for that too. gnu64time anyone?
It's 2023, how about gnu🕛64? ;)

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

[Geert Uytterhoeven]

On Sat, Aug 26, 2023 at 11:00 PM James Le Cuirot
<chewi@aura-online.co.uk> wrote:
> On Sat, 2023-08-26 at 19:24 +0000, Richard wrote:
> > On August 26, 2023 10:51:39 AM UTC, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> > > On Sat, 2023-08-26 at 09:53 +0100, James Le Cuirot wrote:
> > > 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?
>
> Possibly, but I wouldn't know. I suspect it may be the only one still in use
> with Linux. Gentoo supports most of the architectures to some degree, and I'm
> not aware of any those having this issue.

AXIS CRIS was in the same (or a similar) boat, but support for CRIS
was dropped in Linux v4.17.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[John Paul Adrian Glaubitz]

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

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

[Richard]

On August 28, 2023 10:57:25 AM UTC, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
>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.

Assuming anything that is not declared by the c standard is not good imho. The C lang is well known for its pitfalls and the basic binary tools ought not to set bad precedents ignoring those. 

 It is also reasonable to assume that on modern hw cache is filled in blocks of perhaps 1k or more and thus "unnatural" alignment might actually help performance because more fits into that one data burst.

>> Thus.. is there any need to change the kernel ABI?
>
>I don't think this mandates changes to the kernel ABI.

That would be really good, anything else could be handled by library versioning in a mostly backwards compatible way?

Richard 

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

[Geert Uytterhoeven]

Hi Richard,

On Mon, Aug 28, 2023 at 2:12 PM Richard <richiezid@arcor.de> wrote:
> On August 28, 2023 10:57:25 AM UTC, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> >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.
>
> Assuming anything that is not declared by the c standard is not good imho. The C lang is well known for its pitfalls and the basic binary tools ought not to set bad precedents ignoring those.
>
>  It is also reasonable to assume that on modern hw cache is filled in blocks of perhaps 1k or more and thus "unnatural" alignment might actually help performance because more fits into that one data burst.

"1k" (I assume you mean 1 KiB?) is a bit much...

Note that on several architectures you cannot do unaligned accesses,
so you have to declare such a structure with __attribute__((__packed__)),
and thus not only live with the overhead of doing unaligned accesses
from the D-cache, but also in emulating them in software...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[John Paul Adrian Glaubitz]

On Mon, 2023-08-28 at 12:11 +0000, Richard wrote:
> 
> On August 28, 2023 10:57:25 AM UTC, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> > 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.
> 
> Assuming anything that is not declared by the c standard is not good imho. The C
> lang is well known for its pitfalls and the basic binary tools ought not to set
> bad precedents ignoring those. 
> 
> It is also reasonable to assume that on modern hw cache is filled in blocks of perhap
> 1k or more and thus "unnatural" alignment might actually help performance because more
> fits into that one data burst.

This is a very academic discussion really and doesn't really solve the problem we're
seeing. We're here to solve a technical problem, not to discuss whether something is
according to the C standard.

Upstream projects decide on their own what maintenance burden they're willing to accept
and which not. If they don't think it's reasonable to accommodate for the specific m68k
alignment requirements, the burden to keep these packages working are on the distribution
maintainers meaning that I will have to continue spending time unbreaking packages like
OpenJDK in Debian which I prefer not having to in the future.

Adrian

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

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

[Finn Thain]

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.

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

[James Le Cuirot]

On Sun, 2023-08-27 at 10:46 +1000, Finn Thain wrote:
> 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?

Some projects do accept patches. Yann Collet was even kind enough to fix this
in zstd themselves. On the other hand, we have had to fight to stop Python
from dropping m68k support entirely. The real problem is the effort required
to produce these patches. I haven't been able to wrap my head around this so
far, but I would still like to learn. I could see myself eventually fixing
mold, but LLVM feels like a very tall order.

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

If you're referring to time_t, the kernel is not breaking the ABI. New
syscalls were added to 32-bit architectures for 64-bit time_t. The
incompatibility is within userland, such as in the curl vs GnuTLS example I
mentioned.

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

Since this is about userland, are you suggesting that all userland ABIs should
simultaneously support both 32-bit and 64-bit time_t? That would never happen,
especially when 32-bit time_t will naturally become useless.

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

I picked -gnu because this is a variation on what we have already and I've
never heard of glibc using anything other than -gnu*. You still use -gnu when
building with Clang, so I'm not sure what Clang supporting -malign-int has to
do with it. Of course, glibc is not the only libc, but the others are not
compatible anyway and have their own tuples. They will presumably follow suit
though, as they have done in the past, e.g. -gnueabihf -> -musleabihf.

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

I'm not sure what you mean here. I don't think anyone has been prevented from
using the existing ABI when it is the only m68k ABI on Linux. We *are*
considering other architectures with the time_t issue. I haven't heard anyone
shouting about any other common issues. They should really be shouting about
time_t, as it is somewhat pressing, but surprisingly little has been said
about it.

I do know that m68k Linux has been significantly slower since the transition
from linuxthreads to NPTL due to the lack of a spare register, but I gather
nothing can be done about that.

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

[Richard]

On August 27, 2023 9:20:16 AM UTC, James Le Cuirot <chewi@aura-online.co.uk> wrote:
>On Sun, 2023-08-27 at 10:46 +1000, Finn Thain wrote:
>> On Sat, 26 Aug 2023, John Paul Adrian Glaubitz wrote:
>> 
>> > On Sat, 2023-08-26 at 09:53 +0100, James Le Cuirot wrote:
>> 

>> >
>> 
>> If the kernel breaks the ABI, that's a bug, not an excuse. 

...
...

>I do know that m68k Linux has been significantly slower since the transition
>from linuxthreads to NPTL due to the lack of a spare register, but I gather
>nothing can be done about that.

Thanks for saying that. Radically redefining "c" after 35 years of existence for next to zero gain wasn't such a great idea imho.

I hope the kernel ABI can remain stable and everything else is the problem of libraries?

Richard 

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

[Geert Uytterhoeven]

On Sun, Aug 27, 2023 at 11:36 AM James Le Cuirot
<chewi@aura-online.co.uk> wrote:
> On Sun, 2023-08-27 at 10:46 +1000, Finn Thain wrote:
> > 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?
>
> Some projects do accept patches. Yann Collet was even kind enough to fix this
> in zstd themselves. On the other hand, we have had to fight to stop Python
> from dropping m68k support entirely. The real problem is the effort required
> to produce these patches. I haven't been able to wrap my head around this so
> far, but I would still like to learn. I could see myself eventually fixing
> mold, but LLVM feels like a very tall order.

Perhaps we need a new compiler warning: "hole in structure due to
non-natural alignment, please consider adding explicit padding"?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Richard]

On August 28, 2023 7:00:07 AM UTC, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>On Sun, Aug 27, 2023 at 11:36 AM James Le Cuirot
><chewi@aura-online.co.uk> wrote:
>> On Sun, 2023-08-27 at 10:46 +1000, Finn Thain wrote:
>> > 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?
>>
>> Some projects do accept patches. Yann Collet was even kind enough to fix this
>> in zstd themselves. On the other hand, we have had to fight to stop Python
>> from dropping m68k support entirely. The real problem is the effort required
>> to produce these patches. I haven't been able to wrap my head around this so
>> far, but I would still like to learn. I could see myself eventually fixing
>> mold, but LLVM feels like a very tall order.
>
>Perhaps we need a new compiler warning: "hole in structure due to
>non-natural alignment, please consider adding explicit padding"?

Sounds reasonable but I am afraid in 99% of cases this would be completely irrelevant and not break anything so the acceptance would be pretty low. 

The problem arises only when people start doing "strange" things with such structs. Can we define strange things in a better way? It appears to me all modern c standards somewhat lack an attribute to mark a struct as being "special use" and thus emit more warnings and avoid some kinds of trickery.

Richard

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

[Geert Uytterhoeven]

Hi Richard,

On Mon, Aug 28, 2023 at 1:27 PM Richard <richiezid@arcor.de> wrote:
> On August 28, 2023 7:00:07 AM UTC, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >On Sun, Aug 27, 2023 at 11:36 AM James Le Cuirot
> ><chewi@aura-online.co.uk> wrote:
> >> On Sun, 2023-08-27 at 10:46 +1000, Finn Thain wrote:
> >> > 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?
> >>
> >> Some projects do accept patches. Yann Collet was even kind enough to fix this
> >> in zstd themselves. On the other hand, we have had to fight to stop Python
> >> from dropping m68k support entirely. The real problem is the effort required
> >> to produce these patches. I haven't been able to wrap my head around this so
> >> far, but I would still like to learn. I could see myself eventually fixing
> >> mold, but LLVM feels like a very tall order.
> >
> >Perhaps we need a new compiler warning: "hole in structure due to
> >non-natural alignment, please consider adding explicit padding"?
>
> Sounds reasonable but I am afraid in 99% of cases this would be completely irrelevant and not break anything so the acceptance would be pretty low.
>
> The problem arises only when people start doing "strange" things with such structs. Can we define strange things in a better way? It appears to me all modern c standards somewhat lack an attribute to mark a struct as being "special use" and thus emit more warnings and avoid some kinds of trickery.

Do you consider

    struct foo {
            short x;
            int y;
    } bar;

a "strange" thing? In se it's not strange.

Unless someone starts doing:

     assert(sizeof(struct foo) == 8);

or:

    write(fd, &bar, sizeof(bar));

and expects this to be portable/interoperable (ignoring endianness
for now).

IIRC, there are similar issues with the alignment of long long and double
on some 32-bit platforms, where they would not be aligned naturally.

In Linux userspace APIs, we always[*] use natural alignment and
explicit padding.

[*] try to.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Richard]

On August 28, 2023 11:26:58 AM UTC, Richard <richiezid@arcor.de> wrote:
>
>
>
>On August 28, 2023 7:00:07 AM UTC, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>>On Sun, Aug 27, 2023 at 11:36 AM James Le Cuirot
>><chewi@aura-online.co.uk> wrote:
>>> On Sun, 2023-08-27 at 10:46 +1000, Finn Thain wrote:

>>
>>Perhaps we need a new compiler warning: "hole in structure due to
>>non-natural alignment, please consider adding explicit padding"?
>
>Sounds reasonable but I am afraid in 99% of cases this would be completely irrelevant and not break anything so the acceptance would be pretty low. 

On a second thought, that warning might get some acceptance if it is formulated slightly differently.. making it more clear that the way the struct is arranged will waste memory in addition to creating potential portability problems?


Richard

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

[Geert Uytterhoeven]

Hi Richard,

On Mon, Aug 28, 2023 at 10:17 PM Richard <richiezid@arcor.de> wrote:
> On August 28, 2023 11:26:58 AM UTC, Richard <richiezid@arcor.de> wrote:
> >On August 28, 2023 7:00:07 AM UTC, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >>On Sun, Aug 27, 2023 at 11:36 AM James Le Cuirot
> >><chewi@aura-online.co.uk> wrote:
> >>> On Sun, 2023-08-27 at 10:46 +1000, Finn Thain wrote:
> >>Perhaps we need a new compiler warning: "hole in structure due to
> >>non-natural alignment, please consider adding explicit padding"?
> >
> >Sounds reasonable but I am afraid in 99% of cases this would be completely irrelevant and not break anything so the acceptance would be pretty low.
>
> On a second thought, that warning might get some acceptance if it is formulated slightly differently.. making it more clear that the way the struct is arranged will waste memory in addition to creating potential portability problems?

It will not always waste memory, only if some members can be moved
into holes.

Anyway, not wasting memory is merely an optimization.
Creating portability problems is a bug,

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Geert Uytterhoeven]

On Sun, Aug 27, 2023 at 3:03 AM Finn Thain <fthain@linux-m68k.org> wrote:
> 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".

Indeed, the world is slowly turning into "everything is 64-bit little endian"...

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

I guess you mean "ints" and "longs" instead of "shorts"?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[John Paul Adrian Glaubitz]

On Mon, 2023-08-28 at 08:56 +0200, Geert Uytterhoeven wrote:
> > 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".
> 
> Indeed, the world is slowly turning into "everything is 64-bit little endian"...

Well, if we want to prevent that to happen in the future, we should make sure that
the m68k port is prepared for the future.

Adrian

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

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

[Finn Thain]

On Mon, 28 Aug 2023, John Paul Adrian Glaubitz wrote:

> On Mon, 2023-08-28 at 08:56 +0200, Geert Uytterhoeven wrote:
> > > 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".
> > 
> > Indeed, the world is slowly turning into "everything is 64-bit little 
> > endian"...
> 
> Well, if we want to prevent that to happen in the future, we should make 
> sure that the m68k port is prepared for the future.
> 

Agreed. And if we get it right, all those 64-bit architectures will not 
find themselves in the same predicament m68k is in now, once vendors of 
shiny 128-bit and 256-bit architectures start tossing them on the scrap 
heap. How will they avoid that predicament? By following our lead, and 
making struct member alignment decisions explicit.

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

[John Paul Adrian Glaubitz]

On Sun, 2023-08-27 at 10:46 +1000, Finn Thain 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".

It's reasonable to assume that a 32-bit architecture uses 32-bit alignment and
I understand every single upstream project that doesn't want to care about obscure
design the decisions of some ABI designers of the past.

> That is the precedent you would set.

No, I wouldn't set such precedent. I would fix something that has been broken
for years and has caused endless headaches for people maintaining the m68k port
in Linux distributions.

And since we have to break the ABI anyway to be able to use 64-bit time_t, I don't
see any valid reason to stick to the problematic 16-bit alignment used by the current
ABI.

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

The problem aren't upstream projects but the lack of manpower to work on all these
issues. Talk is cheap when there is hardly anyone doing this work.

I have invested a ton of work to get the m68k port into better shape and with the
help of the community, we even managed to land m68k support in LLVM. It was a HUGE
disappointment to me when the 16-bit alignment again caused trouble for a relevant
upstream project on m68k meaning that LLVM can currently not be used natively on
m68k.

> > > 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).

If these users really cared, they would actually help address these issues. I haven't
seen any contributions trying to address these issues outside my efforts and the efforts
of the Gentoo developers.

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

Again, talk is cheap. Show me the code.

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

Yes, I do and that's just my personal opinion. But as I said, I am open to
other naming suggestions.

> 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).

That's why I suggested we can look how the ARM developers will name their
triplet when switching to 64-bit time_t on 32-bit ARM systems.

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

It's a historic architecture. We don't have to redesign everything. It's enough
to address the most pressing issues and these are 16-bit alignment and 32-bit
time_t.

Adrian

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

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

[Adhemerval Zanella Netto]

On 28/08/23 08:10, John Paul Adrian Glaubitz wrote:
> On Sun, 2023-08-27 at 10:46 +1000, Finn Thain 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".
> 
> It's reasonable to assume that a 32-bit architecture uses 32-bit alignment and
> I understand every single upstream project that doesn't want to care about obscure
> design the decisions of some ABI designers of the past.
> 
>> That is the precedent you would set.
> 
> No, I wouldn't set such precedent. I would fix something that has been broken
> for years and has caused endless headaches for people maintaining the m68k port
> in Linux distributions.
> 
> And since we have to break the ABI anyway to be able to use 64-bit time_t, I don't
> see any valid reason to stick to the problematic 16-bit alignment used by the current
> ABI.
> 
>> 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?
> 
> The problem aren't upstream projects but the lack of manpower to work on all these
> issues. Talk is cheap when there is hardly anyone doing this work.
> 
> I have invested a ton of work to get the m68k port into better shape and with the
> help of the community, we even managed to land m68k support in LLVM. It was a HUGE
> disappointment to me when the 16-bit alignment again caused trouble for a relevant
> upstream project on m68k meaning that LLVM can currently not be used natively on
> m68k.
> 
>>>> 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).
> 
> If these users really cared, they would actually help address these issues. I haven't
> seen any contributions trying to address these issues outside my efforts and the efforts
> of the Gentoo developers.
> 
>>>> 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.
> 
> Again, talk is cheap. Show me the code.
> 
>>> 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.
> 
> Yes, I do and that's just my personal opinion. But as I said, I am open to
> other naming suggestions.
> 
>> 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).
> 
> That's why I suggested we can look how the ARM developers will name their
> triplet when switching to 64-bit time_t on 32-bit ARM systems.
> 
>> 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.
> 
> It's a historic architecture. We don't have to redesign everything. It's enough
> to address the most pressing issues and these are 16-bit alignment and 32-bit
> time_t.

If the idea is really to endeavor on a new ABI for m68k, it means a different
loader and the question: will it be interoperable with current m68k ABI in the 
sense that i686 is interoperable with x86_64? It would allow to keep old binaries
running, similar to what old ABI did for 32 to 64 bits transition.

It would require take care that some possible shared data structures (such as 
pthread_mutex_t and alike) have the same layout and alignment, add some support
to ldconfig to differentiated between DSO with different ABIs (either through 
e_flags as ARM, PT_GNU_PROPERTY used by aarch64 or x86_64, or something else),
bump the required minimum kernel (for 64 bit time_t support), and check current
status of the port.

I am bringing the later because I fixed some recent m68k build issues [1], that
seems to be from gcc changes over the years (as hinted by Andreas Schwab) where
compiler changed some internal defined flags and it was not reflected on glibc
(for a short, it seems that -mcpu=680X0 does not already define __mc68020__).
The build fix is straightforward, but it raised question whether something
else is not broken and has not been caught yet.

Waldemar Brodkorb has posted his results on running glibc 2.38 on qemu and
it shows a lot of regression:

    949 FAIL
   3344 PASS
     99 UNSUPPORTED
     16 XFAIL
      2 XPASS

I guess the math failures are from the extra rounding and exception testing, which 
requires a fully compliant IEEE 754 fp unit (which I guess m68k does not provide).
The last m68k testsuite report where from 2.26 release [1] running under ARAnyM,
which shows the port is a better shape.

I also noted that gcc on mc68060 changed the __DEC_EVAL_METHOD__ to 2, which makes 
glibc tests to fail to build (since it assumes __DEC_EVAL_METHOD__ equal 0). This
again raised questions on how the math library would behave depending of the target
chip.

All of this issues and potentially work required for a new ABI makes me wonder
if is really worth to keep *2* distinct ABIs for m68k.  Yes, m68k can follow the
MIPS mess and have 28 different ABIs that fails to be fully interoperable; but
I think that if you really want to on this 'gnu32' journey, I think it will be
better to just deprecate the m68k current ABI, remove it from glibc; and move
everything to new ABI.

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=30740
[2] https://sourceware.org/bugzilla/show_bug.cgi?id=30740#c16
[3] https://sourceware.org/glibc/wiki/Release/2.26#M68K

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

[John Paul Adrian Glaubitz]

Hi Adhemerval!

On Mon, 2023-08-28 at 09:44 -0300, Adhemerval Zanella Netto wrote:
> If the idea is really to endeavor on a new ABI for m68k, it means a different
> loader and the question: will it be interoperable with current m68k ABI in the 
> sense that i686 is interoperable with x86_64? It would allow to keep old binaries
> running, similar to what old ABI did for 32 to 64 bits transition.

OK.

> It would require take care that some possible shared data structures (such as 
> pthread_mutex_t and alike) have the same layout and alignment, add some support
> to ldconfig to differentiated between DSO with different ABIs (either through 
> e_flags as ARM, PT_GNU_PROPERTY used by aarch64 or x86_64, or something else),
> bump the required minimum kernel (for 64 bit time_t support), and check current
> status of the port.

Understood.

> I am bringing the later because I fixed some recent m68k build issues [1], that
> seems to be from gcc changes over the years (as hinted by Andreas Schwab) where
> compiler changed some internal defined flags and it was not reflected on glibc
> (for a short, it seems that -mcpu=680X0 does not already define __mc68020__).
> The build fix is straightforward, but it raised question whether something
> else is not broken and has not been caught yet.
> 
> Waldemar Brodkorb has posted his results on running glibc 2.38 on qemu and
> it shows a lot of regression:
> 
>     949 FAIL
>    3344 PASS
>      99 UNSUPPORTED
>      16 XFAIL
>       2 XPASS
> 
> I guess the math failures are from the extra rounding and exception testing, which 
> requires a fully compliant IEEE 754 fp unit (which I guess m68k does not provide).
> The last m68k testsuite report where from 2.26 release [1] running under ARAnyM,
> which shows the port is a better shape.

The FP failures are most likely the result of the limitations of the FPU emulation
in QEMU for m68k. ARAnyM is known to have much better FPU emulation support than
QEMU, so if you want to have more accurate results, you should test on ARAnyM.

> I also noted that gcc on mc68060 changed the __DEC_EVAL_METHOD__ to 2, which makes 
> glibc tests to fail to build (since it assumes __DEC_EVAL_METHOD__ equal 0). This
> again raised questions on how the math library would behave depending of the target
> chip.
> 
> All of this issues and potentially work required for a new ABI makes me wonder
> if is really worth to keep *2* distinct ABIs for m68k.  Yes, m68k can follow the
> MIPS mess and have 28 different ABIs that fails to be fully interoperable; but
> I think that if you really want to on this 'gnu32' journey, I think it will be
> better to just deprecate the m68k current ABI, remove it from glibc; and move
> everything to new ABI.

I actually wouldn't have a problem with that. I don't plan on supporting the old
ABI with 16-bit alignment. After all, we had to change the ABI for TLS support
as well, didn't we?

Adrian

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

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

[Andreas Schwab]

On Aug 28 2023, John Paul Adrian Glaubitz wrote:

> The FP failures are most likely the result of the limitations of the FPU emulation
> in QEMU for m68k. ARAnyM is known to have much better FPU emulation support than
> QEMU, so if you want to have more accurate results, you should test on ARAnyM.

No, you should test on real hardware.  Neither ARAnyM nor QEMU comes
close.

> After all, we had to change the ABI for TLS support as well, didn't
> we?

Nope.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[John Paul Adrian Glaubitz]

On Mon, 2023-08-28 at 15:17 +0200, Andreas Schwab wrote:
> On Aug 28 2023, John Paul Adrian Glaubitz wrote:
> 
> > The FP failures are most likely the result of the limitations of the FPU emulation
> > in QEMU for m68k. ARAnyM is known to have much better FPU emulation support than
> > QEMU, so if you want to have more accurate results, you should test on ARAnyM.
> 
> No, you should test on real hardware.  Neither ARAnyM nor QEMU comes
> close.

In an ideal world, I would be testing on real hardware, yes. Unfortunately, even on
my Amiga 4000 with 68060/50 MHz the testsuite would run two weeks or so.

> > After all, we had to change the ABI for TLS support as well, didn't
> > we?
> 
> Nope.

So, any binaries from Debian Potato will still work against glibc 2.38 on m68k?

Adrian

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

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

[Geert Uytterhoeven]

Hi Adrian,

On Tue, Aug 29, 2023 at 12:51 PM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Mon, 2023-08-28 at 15:17 +0200, Andreas Schwab wrote:
> > On Aug 28 2023, John Paul Adrian Glaubitz wrote:
> > > After all, we had to change the ABI for TLS support as well, didn't
> > > we?
> >
> > Nope.
>
> So, any binaries from Debian Potato will still work against glibc 2.38 on m68k?

They should.

I regularly boot filesys-ELF-2.0.x-1400K-2.gz, which was created in 1996,
right after m68k switched from a.out to ELF. Any failures are reported
(yes, this does happen, ca. once per decade), and fixed.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[James Le Cuirot]

On Mon, 2023-08-28 at 14:50 +0200, John Paul Adrian Glaubitz wrote:
> Hi Adhemerval!
> 
> On Mon, 2023-08-28 at 09:44 -0300, Adhemerval Zanella Netto wrote:
> > If the idea is really to endeavor on a new ABI for m68k, it means a different
> > loader and the question: will it be interoperable with current m68k ABI in the 
> > sense that i686 is interoperable with x86_64? It would allow to keep old binaries
> > running, similar to what old ABI did for 32 to 64 bits transition.
> 
> OK.

To that, I would add: what old binaries? Linux on m68k is very obscure these
days, with Gentoo, Debian, and NixOS being the only major distributions still
supporting it. As the Gentoo m68k maintainer, I would not expect users to be
pulling binaries from elsewhere, and I imagine Adrian would say the same.
Where would you even get them from? I thought there might be a handful on
Aminet, but I cannot even find any there.

Upgrading an existing system might be awkward, but time_t alone will probably
warrant a reinstall. Having said that, I just tried a somewhat unscientific
experiment of running a bunch of random binaries from my 32-bit aligned system
on my 16-bit aligned one and nothing broke. I then tried the reverse and saw
stash smashing detection kicking in on anything more complex than ls.

> > I am bringing the later because I fixed some recent m68k build issues [1], that
> > seems to be from gcc changes over the years (as hinted by Andreas Schwab) where
> > compiler changed some internal defined flags and it was not reflected on glibc
> > (for a short, it seems that -mcpu=680X0 does not already define __mc68020__).
> > The build fix is straightforward, but it raised question whether something
> > else is not broken and has not been caught yet.

I had been aware of that issue for a while, but I wasn't able to figure it out
in a few minutes, and I never got around to looking deeper. Sorry for not
reporting it sooner.

> > Waldemar Brodkorb has posted his results on running glibc 2.38 on qemu and
> > it shows a lot of regression:
> > 
> >     949 FAIL
> >    3344 PASS
> >      99 UNSUPPORTED
> >      16 XFAIL
> >       2 XPASS
> > 
> > I guess the math failures are from the extra rounding and exception testing, which 
> > requires a fully compliant IEEE 754 fp unit (which I guess m68k does not provide).
> > The last m68k testsuite report where from 2.26 release [1] running under ARAnyM,
> > which shows the port is a better shape.
> 
> The FP failures are most likely the result of the limitations of the FPU emulation
> in QEMU for m68k. ARAnyM is known to have much better FPU emulation support than
> QEMU, so if you want to have more accurate results, you should test on ARAnyM.

This is fairly typical of the math-related test failures I have seen from
other projects. I hadn't realised that QEMU's FPU emulation was lacking and
had just chalked it up to m68k's FP hardware having different capabilities.
Either way, I have never noticed any issues here when using software in
practise. Not that I've done any heavy number crunching on m68k, but who
would?

> > I also noted that gcc on mc68060 changed the __DEC_EVAL_METHOD__ to 2, which makes 
> > glibc tests to fail to build (since it assumes __DEC_EVAL_METHOD__ equal 0). This
> > again raised questions on how the math library would behave depending of the target
> > chip.
> > 
> > All of this issues and potentially work required for a new ABI makes me wonder
> > if is really worth to keep *2* distinct ABIs for m68k.  Yes, m68k can follow the
> > MIPS mess and have 28 different ABIs that fails to be fully interoperable; but
> > I think that if you really want to on this 'gnu32' journey, I think it will be
> > better to just deprecate the m68k current ABI, remove it from glibc; and move
> > everything to new ABI.
> 
> I actually wouldn't have a problem with that. I don't plan on supporting the old
> ABI with 16-bit alignment. After all, we had to change the ABI for TLS support
> as well, didn't we?

I don't want to force anyone here, but I'd also be fine with that. The only
downside, apart from compatibility, appears to be slightly increased memory
usage, and you're not exactly going to run modern Linux with 8MB RAM anyway.

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

[John Paul Adrian Glaubitz]

On Mon, 2023-08-28 at 14:29 +0100, James Le Cuirot wrote:
> On Mon, 2023-08-28 at 14:50 +0200, John Paul Adrian Glaubitz wrote:
> > Hi Adhemerval!
> > 
> > On Mon, 2023-08-28 at 09:44 -0300, Adhemerval Zanella Netto wrote:
> > > If the idea is really to endeavor on a new ABI for m68k, it means a different
> > > loader and the question: will it be interoperable with current m68k ABI in the 
> > > sense that i686 is interoperable with x86_64? It would allow to keep old binaries
> > > running, similar to what old ABI did for 32 to 64 bits transition.
> > 
> > OK.
> 
> To that, I would add: what old binaries? Linux on m68k is very obscure these
> days, with Gentoo, Debian, and NixOS being the only major distributions still
> supporting it. As the Gentoo m68k maintainer, I would not expect users to be
> pulling binaries from elsewhere, and I imagine Adrian would say the same.
> Where would you even get them from? I thought there might be a handful on
> Aminet, but I cannot even find any there.

Fully agreed.

> Upgrading an existing system might be awkward, but time_t alone will probably
> warrant a reinstall. Having said that, I just tried a somewhat unscientific
> experiment of running a bunch of random binaries from my 32-bit aligned system
> on my 16-bit aligned one and nothing broke. I then tried the reverse and saw
> stash smashing detection kicking in on anything more complex than ls.

Thanks so much for performing such tests. This is really appreciated and provides
valuable information that's very helpful for the transition process.

> > 
> > most likely the result of the limitations of the FPU emulation
> > in QEMU for m68k. ARAnyM is known to have much better FPU emulation support than
> > QEMU, so if you want to have more accurate results, you should test on ARAnyM.
> 
> This is fairly typical of the math-related test failures I have seen from
> other projects. I hadn't realised that QEMU's FPU emulation was lacking and
> had just chalked it up to m68k's FP hardware having different capabilities.
> Either way, I have never noticed any issues here when using software in
> practise. Not that I've done any heavy number crunching on m68k, but who
> would?

There have always been FPU-relevant issues on both QEMU and Aranym although it's
better on Aranym than on QEMU. This is a well known issue.

> > > I also noted that gcc on mc68060 changed the __DEC_EVAL_METHOD__ to 2, which makes 
> > > glibc tests to fail to build (since it assumes __DEC_EVAL_METHOD__ equal 0). This
> > > again raised questions on how the math library would behave depending of the target
> > > chip.
> > > 
> > > All of this issues and potentially work required for a new ABI makes me wonder
> > > if is really worth to keep *2* distinct ABIs for m68k.  Yes, m68k can follow the
> > > MIPS mess and have 28 different ABIs that fails to be fully interoperable; but
> > > I think that if you really want to on this 'gnu32' journey, I think it will be
> > > better to just deprecate the m68k current ABI, remove it from glibc; and move
> > > everything to new ABI.
> > 
> > I actually wouldn't have a problem with that. I don't plan on supporting the old
> > ABI with 16-bit alignment. After all, we had to change the ABI for TLS support
> > as well, didn't we?
> 
> I don't want to force anyone here, but I'd also be fine with that. The only
> downside, apart from compatibility, appears to be slightly increased memory
> usage, and you're not exactly going to run modern Linux with 8MB RAM anyway.

Agreed. And I finally want to be able to use Rust and LLVM on m68k ;-).

Adrian

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

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

[Karoly Balogh]

Hi,

On Tue, 29 Aug 2023, John Paul Adrian Glaubitz wrote:

> > I don't want to force anyone here, but I'd also be fine with that. The only
> > downside, apart from compatibility, appears to be slightly increased memory
> > usage, and you're not exactly going to run modern Linux with 8MB RAM anyway.
>
> Agreed. And I finally want to be able to use Rust and LLVM on m68k ;-).

So, let me get this straight (or from anothe perspective if you will) -
neither LLVM and Rust is ready for prime time, because it can't accomodate
a decade old established standard on our platform. But Linux maintainers
rush forward, and break^Wchange the ABI, so we can accomodate some
half-baked fancy new tools.

Sometime later someone realizes: if you want to support any other system
on m68k (Amiga, Atari, 68k Mac, *BSD, game consoles (embedded) you name
it), you still need to add support for the original alignment
restrictions, because on those systems you're not always going to be able
recompile the $world. So that someone will have the skills to add the
needed changes to these tools, so they can finally mature and accommodate
more real world scenarios that are out there.

At that point Linux m68k broke their own ABI for no reason, but because
someone couldn't wait until the necessary work was done, instead of
hacking problems around.

Ask me if I've seen this already (elsewhere).

Best,
--
Charlie

(Ps: Also, IMO the Itanium analogy is totally bogus. Itanium never had the
history and the historical significance of m68k, and the hardware has been
always been an expensive toy for a select few, with a few having any sort
of self-motivating emotional attachment to it. Also, where you draw the
line? At which point are we going to do a little endian ABI for m68k, so
upstream can ignore big endian? Don't laugh, apart from the well known
ppc64le case by IBM, this has been done the other in an m68k-context too,
but the other way around - a big-endian x86 GCC, so you can compile Amiga
ABI compatible libraries that contain native x86 code on emulators...)

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

[Jeffrey Walton]

On Tue, Aug 29, 2023 at 5:53 PM Karoly Balogh via Libc-help
<libc-help@sourceware.org> wrote:
>
> On Tue, 29 Aug 2023, John Paul Adrian Glaubitz wrote:
>
> > > I don't want to force anyone here, but I'd also be fine with that. The only
> > > downside, apart from compatibility, appears to be slightly increased memory
> > > usage, and you're not exactly going to run modern Linux with 8MB RAM anyway.
> >
> > Agreed. And I finally want to be able to use Rust and LLVM on m68k ;-).
>
> So, let me get this straight (or from anothe perspective if you will) -
> neither LLVM and Rust is ready for prime time, because it can't accomodate
> a decade old established standard on our platform. But Linux maintainers
> rush forward, and break^Wchange the ABI, so we can accomodate some
> half-baked fancy new tools.

Regarding Rust, it is only guaranteed to work on x86_64 and Aarch64.
Other platforms are a roll of the dice. See
https://doc.rust-lang.org/nightly/rustc/platform-support.html.

In practice, we had to scrap a project that was based on Rust. It gave
us too many problems on armel, armhf, aarch64 and powerpc. Rust could
not even compile its own cargos. We rebooted and went back to C. (This
was several years ago, before Aarch64 became Tier I).

> Sometime later someone realizes: if you want to support any other system
> on m68k (Amiga, Atari, 68k Mac, *BSD, game consoles (embedded) you name
> it), you still need to add support for the original alignment
> restrictions, because on those systems you're not always going to be able
> recompile the $world. So that someone will have the skills to add the
> needed changes to these tools, so they can finally mature and accommodate
> more real world scenarios that are out there.
>
> At that point Linux m68k broke their own ABI for no reason, but because
> someone couldn't wait until the necessary work was done, instead of
> hacking problems around.

Jeff

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

[Finn Thain]

On Mon, 28 Aug 2023, John Paul Adrian Glaubitz wrote:

> 
> And since we have to break the ABI anyway to be able to use 64-bit 
> time_t

If you're worried about Y2038, aren't you jumping the gun? I reckon we 
have about 10 years in which to figure out what a better m68k ABI should 
look like.

> I don't see any valid reason to stick to the problematic 16-bit 
> alignment used by the current ABI.
> 

Well, here are a few reasons why all those padding patches you wrote were 
a good thing (besides the obvious benefit of avoiding an ABI break):

- That code is now more portable among projects which care about 
  portability to 16-bit platforms etc.

- Explicit alignment reveals suboptimal cache footprint and wasted memory.

- Data structures often outlive the software that introduced them. It's 
  safe to say that the struct definitions you fixed will produce a benefit 
  you may never hear about, by virtue of code re-use.

> ...
> > 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.
> 
> It's a historic architecture. We don't have to redesign everything. 

Coldfire is still shipping (is it "historic" yet?). Not sure about Apollo 
68080 and Buffee BP68040. Most likely TG68K and Pistorm will end up 
gaining whatever features Linux requires (MMU etc.).

If we get the ABI right, such designs can benefit if it allows them to go 
beyond 680x0 and better exploit the FPGA they may be implemented on.
(Dare I mention SMP?)

Considering just Coldfire for a moment, one question we could look at is, 
how could the ABI be changed to permit the same binaries to work 
efficiently on both kernels (CF and 680x0)?

It seems likely that ABI changes could potentially help to accelerate 68k 
emulators.

Inefficient thread local storage is an issue that might be addressed with 
VDSO calls rather than an ABI break.

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

[Eero Tamminen]

Hi,

On 29.8.2023 4.14, Finn Thain wrote:
> On Mon, 28 Aug 2023, John Paul Adrian Glaubitz wrote:
>> And since we have to break the ABI anyway to be able to use 64-bit
>> time_t
> 
> If you're worried about Y2038, aren't you jumping the gun? I reckon we
> have about 10 years in which to figure out what a better m68k ABI should
> look like.

Debian is discussing LFS + time_t transition for the next release, for 
all architectures.  They are related, and if one needs to break / 
transition ABI, doing it once is better than doing it twice...

LWN has summary of the discussion: https://lwn.net/Articles/938149/


	- Eero

Python requires 32-bit alignment now - was: Re: Tuple and changes for m68k with -malign-int

[John Paul Adrian Glaubitz]

Hi,

On Sat, 2023-08-26 at 12:51 +0200, John Paul Adrian Glaubitz wrote:
> > 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:
> 
> - LLVM
> - Firebird Database
> - OpenJDK
> - Various Qt packages

We can now add CPython to this list as 3.13 requires 32-bit alignment [1]:

In file included from ../Include/internal/pycore_backoff.h:12,
                 from ../Include/internal/pycore_code.h:474,
                 from ../Include/internal/pycore_interp.h:16,
                 from ../Include/internal/pycore_runtime.h:17,
                 from ../Include/internal/pycore_pystate.h:12,
                 from ../Include/internal/pycore_critical_section.h:9,
                 from ../Python/critical_section.c:4:
../Python/critical_section.c:6:1: error: static assertion failed: "critical section must be aligned to at least 4 bytes"
    6 | static_assert(_Alignof(_PyCriticalSection) >= 4,
      | ^~~~~~~~~~~~~

We should really make the switch now. It's certainly not getting better.

Adrian

> [1] https://buildd.debian.org/status/fetch.php?pkg=python3.13&arch=m68k&ver=3.13.0%7Eb1-2&stamp=1715773703&raw=0

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

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

[John Paul Adrian Glaubitz]

Hi James,

On Sat, 2023-08-26 at 09:53 +0100, James Le Cuirot wrote:
> Once that is agreed, I'm happy to put together the patch to automatically
> enable the flag for this tuple in GCC. The part I do need help with is
> necessary changes to glibc, if any. Assembly is not my area at all, so what I
> came up with here was a total guess.
> 
> 
> --- a/sysdeps/m68k/crti.S       2022-07-29 23:03:09.000000000 +0100
> +++ b/sysdeps/m68k/crti.S       2022-11-30 21:41:52.710135230 +0000
> @@ -56,7 +56,7 @@
>  #endif
>  
>         .section .init,"ax",@progbits
> -       .align  2
> +       .p2align        2
>         .globl  _init
>         .hidden _init
>         .type   _init, @function
> @@ -74,7 +74,7 @@
>  #endif
>  
>         .section .fini,"ax",@progbits
> -       .align  2
> +       .p2align        2
>         .globl  _fini
>         .hidden _fini
>         .type   _fini, @function
> 
> 
> I did try this out, and it largely seemed to work, although processes
> occasionally hung. Perhaps this was unrelated.

I was just looking at the necessary changes to switch m68k to 32-bit alignment
and I'm not sure we need to do anything about glibc. I am documenting my current
findings here [1].

What I have found out so far is that official ELF ABI documentation from AT&T
mandates a default alignment of four bytes and any SVR4-based distribution such
as Amiga Unix and NetBSD/ELF actually adheres to that. Why Linux uses a 2 bytes
alignment when the official ELF ABI documentation clearly says 4 bytes, remains
a mystery to me.

I'm not even sure whether we would have to change the target triplet since the
current implementation for Linux is actually violating the standard and any
application adhering to spec written for Linux ELF m68k would actually not work.

Anyway, looking at crti.s for other 32-bit architectures such as powerpc, I'm not
sure we actually need to do anything about glibc. I think just changing the
default value for BIGGEST_ALIGNMENT from 16 to 64 similar to NetBSD/ELF in GCC
should be enough, shouldn't it?

Adrian

> [1] https://wiki.debian.org/M68k/Alignment

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

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

[Antonio Vargas Gonzalez]

On Sun, May 18, 2025 at 9:09 AM 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:
> > Once that is agreed, I'm happy to put together the patch to automatically
> > enable the flag for this tuple in GCC. The part I do need help with is
> > necessary changes to glibc, if any. Assembly is not my area at all, so what I
> > came up with here was a total guess.
> >
> >
> > --- a/sysdeps/m68k/crti.S       2022-07-29 23:03:09.000000000 +0100
> > +++ b/sysdeps/m68k/crti.S       2022-11-30 21:41:52.710135230 +0000
> > @@ -56,7 +56,7 @@
> >  #endif
> >
> >         .section .init,"ax",@progbits
> > -       .align  2
> > +       .p2align        2
> >         .globl  _init
> >         .hidden _init
> >         .type   _init, @function
> > @@ -74,7 +74,7 @@
> >  #endif
> >
> >         .section .fini,"ax",@progbits
> > -       .align  2
> > +       .p2align        2
> >         .globl  _fini
> >         .hidden _fini
> >         .type   _fini, @function
> >
> >
> > I did try this out, and it largely seemed to work, although processes
> > occasionally hung. Perhaps this was unrelated.
>
> I was just looking at the necessary changes to switch m68k to 32-bit alignment
> and I'm not sure we need to do anything about glibc. I am documenting my current
> findings here [1].
>
> What I have found out so far is that official ELF ABI documentation from AT&T
> mandates a default alignment of four bytes and any SVR4-based distribution such
> as Amiga Unix and NetBSD/ELF actually adheres to that. Why Linux uses a 2 bytes
> alignment when the official ELF ABI documentation clearly says 4 bytes, remains
> a mystery to me.

It correlates with the default in AmigaOS, which was originally
optimized to fit in 256K of RAM.

> I'm not even sure whether we would have to change the target triplet since the
> current implementation for Linux is actually violating the standard and any
> application adhering to spec written for Linux ELF m68k would actually not work.
>
> Anyway, looking at crti.s for other 32-bit architectures such as powerpc, I'm not
> sure we actually need to do anything about glibc. I think just changing the
> default value for BIGGEST_ALIGNMENT from 16 to 64 similar to NetBSD/ELF in GCC
> should be enough, shouldn't it?
>
> Adrian
>
> > [1] https://wiki.debian.org/M68k/Alignment
>
> --
>  .''`.  John Paul Adrian Glaubitz
> : :' :  Debian Developer
> `. `'   Physicist
>   `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>


-- 
Antonio Vargas Gonzalez | winden ^ capsule ^ rgba ^ network ^
batman.group | +windenntw | windenntw@gmail.com

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

[John Paul Adrian Glaubitz]

On Sun, 2025-05-18 at 16:39 +0200, Antonio Vargas Gonzalez wrote:
> It correlates with the default in AmigaOS, which was originally
> optimized to fit in 256K of RAM.

AmigaOS doesn't use ELF though, it uses COFF. And Amiga Unix, which uses
ELF, has a default alignment of 4 bytes as specified by the AT&T ABI.

Adrian

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

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

[Geert Uytterhoeven]

Hi Adrian,

On Sun, 18 May 2025 at 17:07, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Sun, 2025-05-18 at 16:39 +0200, Antonio Vargas Gonzalez wrote:
> > It correlates with the default in AmigaOS, which was originally
> > optimized to fit in 256K of RAM.
>
> AmigaOS doesn't use ELF though, it uses COFF. And Amiga Unix, which uses
> ELF, has a default alignment of 4 bytes as specified by the AT&T ABI.

Initially Linux didn't use ELF either, but a.out.
SunOS4 (based on BSD) did use 2-byte alignment on m68k, so I am still
surprised NetBSD didn't follow suit.
SunOS5 (based on SVR4) no longer supported m68k.

I expect (the history of) the gcc sources would tell you more about
the default alignment on other (legacy UNIX) OSes supporting m68k...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[John Paul Adrian Glaubitz]

Hi Geert,

On Mon, 2025-05-19 at 09:42 +0200, Geert Uytterhoeven wrote:
> > AmigaOS doesn't use ELF though, it uses COFF. And Amiga Unix, which uses
> > ELF, has a default alignment of 4 bytes as specified by the AT&T ABI.
> 
> Initially Linux didn't use ELF either, but a.out.

Yes, the same applies for NetBSD. This also becomes obvious that the
NetBSD header on m68k is called "netbsd-elf.h", instead of just "netbsd.h".

> SunOS4 (based on BSD) did use 2-byte alignment on m68k, so I am still
> surprised NetBSD didn't follow suit.

When NetBSD still used a.out, it actually used 2 bytes alignment. They
switched over when they switched from a.out to ELF, see:

https://wiki.debian.org/M68k/Alignment

> SunOS5 (based on SVR4) no longer supported m68k.

True. I would now be really interested to find out what my Sony NEWS
machines use on m68k. According to Wikipedia, it's based on SVR4, so
I assume it uses ELF with 4 bytes alignment, see:

https://en.wikipedia.org/wiki/UNIX_System_V#SVR4

There is also an Atari Unix which I would like to test as well.

> I expect (the history of) the gcc sources would tell you more about
> the default alignment on other (legacy UNIX) OSes supporting m68k...

Good idea. I will do that. My assumption is that on Linux, GCC developers
actually just forgot to switch alignment from 2 to 4 bytes with the switch
to ELF unlike NetBSD.

Adrian

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

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

[Andreas Schwab]

On Mai 19 2025, John Paul Adrian Glaubitz wrote:

> Good idea. I will do that. My assumption is that on Linux, GCC developers
> actually just forgot to switch alignment from 2 to 4 bytes with the switch
> to ELF unlike NetBSD.

The Linux developers care about backward compatilibity.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

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

[John Paul Adrian Glaubitz]

On Mon, 2025-05-19 at 10:03 +0200, Andreas Schwab wrote:
> On Mai 19 2025, John Paul Adrian Glaubitz wrote:
> 
> > Good idea. I will do that. My assumption is that on Linux, GCC developers
> > actually just forgot to switch alignment from 2 to 4 bytes with the switch
> > to ELF unlike NetBSD.
> 
> The Linux developers care about backward compatilibity.

That makes no sense though as a.out and ELF binaries are not compatible, are they?

Adrian

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

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

[Geert Uytterhoeven]

Hi Adrian,

On Mon, 19 May 2025 at 10:18, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Mon, 2025-05-19 at 10:03 +0200, Andreas Schwab wrote:
> > On Mai 19 2025, John Paul Adrian Glaubitz wrote:
> >
> > > Good idea. I will do that. My assumption is that on Linux, GCC developers
> > > actually just forgot to switch alignment from 2 to 4 bytes with the switch
> > > to ELF unlike NetBSD.
> >
> > The Linux developers care about backward compatilibity.
>
> That makes no sense though as a.out and ELF binaries are not compatible, are they?

The syscall ABI is.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[John Paul Adrian Glaubitz]

Hi Geert,

On Mon, 2025-05-19 at 10:25 +0200, Geert Uytterhoeven wrote:
> On Mon, 19 May 2025 at 10:18, John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> > On Mon, 2025-05-19 at 10:03 +0200, Andreas Schwab wrote:
> > > On Mai 19 2025, John Paul Adrian Glaubitz wrote:
> > > 
> > > > Good idea. I will do that. My assumption is that on Linux, GCC developers
> > > > actually just forgot to switch alignment from 2 to 4 bytes with the switch
> > > > to ELF unlike NetBSD.
> > > 
> > > The Linux developers care about backward compatilibity.
> > 
> > That makes no sense though as a.out and ELF binaries are not compatible, are they?
> 
> The syscall ABI is.

Fair enough. But a.out is long gone now and anyone who runs Linux/m68k these days does
that as a hobbyist. I think that the advantages of fixing several dozens of alignment
bugs once and for all hugely outweighs the disadvantage of breaking compatibility with
old binaries.

If I understand correctly, there was an (unintended) ABI break on Linux/s390 as well
and it seems that it was not reverted [1]. Maybe someone involved in this discussion
from back then can comment.

Adrian

> [1] https://lwn.net/Articles/605607/

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

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

[Geert Uytterhoeven]

Hi Adrian,

On Mon, 19 May 2025 at 09:54, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Mon, 2025-05-19 at 09:42 +0200, Geert Uytterhoeven wrote:
> > I expect (the history of) the gcc sources would tell you more about
> > the default alignment on other (legacy UNIX) OSes supporting m68k...
>
> Good idea. I will do that. My assumption is that on Linux, GCC developers
> actually just forgot to switch alignment from 2 to 4 bytes with the switch
> to ELF unlike NetBSD.

Linux/m68k ELF and a.out were deliberately kept compatible, and
coexisted together for a brief moment in time.

The NetBSD kernel and userland are a single system built from source
maintained together, so a recompile of everything was never considered
a big issue.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Florian Weimer]

* John Paul Adrian Glaubitz via Libc-help:

> I was just looking at the necessary changes to switch m68k to 32-bit alignment
> and I'm not sure we need to do anything about glibc. I am documenting my current
> findings here [1].

>> [1] https://wiki.debian.org/M68k/Alignment

Why doesn't this change need a new target triple?  This change alters
struct layout (it introduces new padding in some cases), so it's quite
incompatible with what we have today.

Thanks,
Florian

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

[John Paul Adrian Glaubitz]

On Mon, 2025-05-19 at 10:14 +0200, Florian Weimer wrote:
> * John Paul Adrian Glaubitz via Libc-help:
> 
> > I was just looking at the necessary changes to switch m68k to 32-bit alignment
> > and I'm not sure we need to do anything about glibc. I am documenting my current
> > findings here [1].
> 
> > > [1] https://wiki.debian.org/M68k/Alignment
> 
> Why doesn't this change need a new target triple?  This change alters
> struct layout (it introduces new padding in some cases), so it's quite
> incompatible with what we have today.

My argument is that Linux/m68k is a pure hobbyist project and anyone involved
can deal with the changes coming from the alignment change.

Introducing a new triplet would mean having to accommodate for that in other
projects which only know "m68k-(unknown-)linux-gnu.

Adrian

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

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

[James Le Cuirot]

On Mon, 2025-05-19 at 10:24 +0200, John Paul Adrian Glaubitz wrote:
> On Mon, 2025-05-19 at 10:14 +0200, Florian Weimer wrote:
> > * John Paul Adrian Glaubitz via Libc-help:
> > 
> > > I was just looking at the necessary changes to switch m68k to 32-bit alignment
> > > and I'm not sure we need to do anything about glibc. I am documenting my current
> > > findings here [1].
> > 
> > > > [1] https://wiki.debian.org/M68k/Alignment
> > 
> > Why doesn't this change need a new target triple?  This change alters
> > struct layout (it introduces new padding in some cases), so it's quite
> > incompatible with what we have today.
> 
> My argument is that Linux/m68k is a pure hobbyist project and anyone involved
> can deal with the changes coming from the alignment change.
> 
> Introducing a new triplet would mean having to accommodate for that in other
> projects which only know "m68k-(unknown-)linux-gnu.

For what it's worth, while Adrian and I are largely aligned (haha) on this
change, myself and others in Gentoo do intend to use a new tuple. The current
plan is to do this at the same time as time64, which we believe also requires
new tuples, despite Debian sticking the same ones there as well. We are aware
that other projects will require adjusting, but we'll just deal with it.

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

[John Paul Adrian Glaubitz]

On Mon, 2025-05-19 at 22:51 +0100, James Le Cuirot wrote:
> For what it's worth, while Adrian and I are largely aligned (haha) on this
> change, myself and others in Gentoo do intend to use a new tuple. The current
> plan is to do this at the same time as time64, which we believe also requires
> new tuples, despite Debian sticking the same ones there as well. We are aware
> that other projects will require adjusting, but we'll just deal with it.

But what's the point for doing this? Are you worried that the three users of the
port are going to have to reinstall their systems? Does this really justify carrying
patches for many other packages?

Adrian

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

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

[James Le Cuirot]

On Tue, 2025-05-20 at 11:39 +0200, John Paul Adrian Glaubitz wrote:
> On Mon, 2025-05-19 at 22:51 +0100, James Le Cuirot wrote:
> > For what it's worth, while Adrian and I are largely aligned (haha) on this
> > change, myself and others in Gentoo do intend to use a new tuple. The current
> > plan is to do this at the same time as time64, which we believe also requires
> > new tuples, despite Debian sticking the same ones there as well. We are aware
> > that other projects will require adjusting, but we'll just deal with it.
> 
> But what's the point for doing this? Are you worried that the three users of the
> port are going to have to reinstall their systems? Does this really justify carrying
> patches for many other packages?

Obviously, time64 affects a lot more than just m68k, and if we're doing it for
that, then we might as well do it for -malign-int at the same time. I wasn't
really involved in the decision, but I think it's because Gentoo is a rolling
source-based distro, so ideally we need a way for users to migrate their
existing systems.

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

[John Paul Adrian Glaubitz]

On Wed, 2025-05-21 at 10:15 +0100, James Le Cuirot wrote:
> > But what's the point for doing this? Are you worried that the three users of the
> > port are going to have to reinstall their systems? Does this really justify carrying
> > patches for many other packages?
> 
> Obviously, time64 affects a lot more than just m68k, and if we're doing it for
> that, then we might as well do it for -malign-int at the same time. I wasn't
> really involved in the decision, but I think it's because Gentoo is a rolling
> source-based distro, so ideally we need a way for users to migrate their
> existing systems.

Okay, valid point. I wasn't thinking about time64_t at this point but just -malign-int.

Adrian

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

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

[Finn Thain]

On Mon, 19 May 2025, John Paul Adrian Glaubitz wrote:

> 
> My argument is that Linux/m68k is a pure hobbyist project and anyone 
> involved can deal with the changes coming from the alignment change.
> 

If hobbyists can deal with ABI breakage, they can certainly deal with the 
longstanding lack of fancy toolchains and toolkits*.

But you're being presumtuous. Your hobby may be the porting of fancy 
toolchains. It's not mine!

There's no such thing as a "pure hobbyist" Linux port. This is a 
collaborative effort. Debian/m68k needs corporations just as RHEL needs 
volunteers.

* https://lists.debian.org/debian-68k/2024/10/msg00001.html

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

[John Paul Adrian Glaubitz]

On Tue, 2025-05-20 at 07:59 +1000, Finn Thain wrote:
> On Mon, 19 May 2025, John Paul Adrian Glaubitz wrote:
> 
> > 
> > My argument is that Linux/m68k is a pure hobbyist project and anyone 
> > involved can deal with the changes coming from the alignment change.
> > 
> 
> If hobbyists can deal with ABI breakage, they can certainly deal with the 
> longstanding lack of fancy toolchains and toolkits*.

Being able to build the build dependencies of cmake or parts of GCC such
as gccgo is not something I would consider "fancy". Furthermore, more and
more packages are being ported to Rust which means m68k will either die
a long death or have to switch to 4 bytes alignment.

> But you're being presumtuous. Your hobby may be the porting of fancy 
> toolchains. It's not mine!

I am not asking you as you're not involved in maintaining Debian/m68k.

> There's no such thing as a "pure hobbyist" Linux port. This is a 
> collaborative effort. Debian/m68k needs corporations just as RHEL needs 
> volunteers.

Can you point me to anyone else who is involved in Debian/m68k except me?

Adrian

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

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

[Geert Uytterhoeven]

Hi Adrian,

On Tue, 20 May 2025 at 09:56, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Tue, 2025-05-20 at 07:59 +1000, Finn Thain wrote:
> > On Mon, 19 May 2025, John Paul Adrian Glaubitz wrote:
> > > My argument is that Linux/m68k is a pure hobbyist project and anyone
> > > involved can deal with the changes coming from the alignment change.
> >
> > If hobbyists can deal with ABI breakage, they can certainly deal with the
> > longstanding lack of fancy toolchains and toolkits*.
>
> Being able to build the build dependencies of cmake or parts of GCC such
> as gccgo is not something I would consider "fancy". Furthermore, more and
> more packages are being ported to Rust which means m68k will either die
> a long death or have to switch to 4 bytes alignment.

Is this a Rust or LLVM issue?
In case of the latter, how is llvm-mos coping?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[John Paul Adrian Glaubitz]

On Tue, 2025-05-20 at 10:24 +0200, Geert Uytterhoeven wrote:
> Is this a Rust or LLVM issue?
> In case of the latter, how is llvm-mos coping?

It's an issue with a lot of packages as I have documented here:

https://wiki.debian.org/M68k/Alignment

While you could argue whether packages like OpenJDK or Go are fancy,
the problem is that they are build dependencies for a lot of other
packages, either directly or transitively.

For example, cmake has build dependencies on Qt which in turn requires
4 bytes alignment to build. In turn, several thousand packages have cmake
as their build dependency, so waiving for cmake is not really a constructive
suggestion to make.

And I really don't want to keep patching stuff forever manually and upload
it to Debian unreleased. It's a pure waste of time which is better spent
on fixing actual bugs.

I really don't understand why people that claim to be interested in the
m68k port constantly block any kind of changes that would actually improve
the port and prepare it for the future.

And I also don't understand why this is even an issue. If someone insists
on using 2 bytes alignment, just stick to your old chroot. If you're not
interested in new, "fancy" packages, just don't upgrade or install Debian
Etch or similar. Changing the default alignment does not affect existing
software.

The fact is that software is moving forward which also means it's adopting
new languages like Rust. New languages make certain assumptions about the
target such as the minimum alignment. And if we want to be able to build
updated packages for m68k, we have to switch the default alignment.

What do people that object the alignment change suggest as an alternative?
Tell the rest of the Linux community not to use Rust? Tell them not to use
Go?

I don't get it.

Adrian

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

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

[Finn Thain]

On Tue, 20 May 2025, John Paul Adrian Glaubitz wrote:

> The fact is that software is moving forward 

Right. That's why we now have "Qt for MCUs". The Qt developers aren't 
trying to sell Qt 6 into a market that doesn't have sufficient compute 
power. And yet, for some reason, that's what you're advocating. You seem 
to think that the Debian archive has not grown since Debian etch. I don't 
get it.

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

[John Paul Adrian Glaubitz]

On Tue, 2025-05-20 at 19:46 +1000, Finn Thain wrote:
> On Tue, 20 May 2025, John Paul Adrian Glaubitz wrote:
> 
> > The fact is that software is moving forward 
> 
> Right. That's why we now have "Qt for MCUs". The Qt developers aren't 
> trying to sell Qt 6 into a market that doesn't have sufficient compute 
> power. And yet, for some reason, that's what you're advocating. You seem 
> to think that the Debian archive has not grown since Debian etch. I don't 
> get it.

No, you seem to think that software has stopped moving since 1988 and for
some reason you enjoying criticizing people that try to keep a port alive.

You haven't contributed a single constructive comment to this whole discussion,
you just keep saying that you don't want changes but you also don't want to
help to fix problems.

This isn't helpful.

Adrian

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

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

[Geert Uytterhoeven]

Hi Adrian,

On Tue, 20 May 2025 at 10:38, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> And I also don't understand why this is even an issue. If someone insists
> on using 2 bytes alignment, just stick to your old chroot. If you're not

What about kernel/userland compatibility?

> interested in new, "fancy" packages, just don't upgrade or install Debian
> Etch or similar. Changing the default alignment does not affect existing
> software.

What about existing software that is aware the minimum alignment is
2-bytes on m68k?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[John Paul Adrian Glaubitz]

On Tue, 2025-05-20 at 11:58 +0200, Geert Uytterhoeven wrote:
> On Tue, 20 May 2025 at 10:38, John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> > And I also don't understand why this is even an issue. If someone insists
> > on using 2 bytes alignment, just stick to your old chroot. If you're not
> 
> What about kernel/userland compatibility?

What about it? This is about userland.

> > interested in new, "fancy" packages, just don't upgrade or install Debian
> > Etch or similar. Changing the default alignment does not affect existing
> > software.
> 
> What about existing software that is aware the minimum alignment is
> 2-bytes on m68k?

Can you name some cases? I would love to add these to my list.

Thanks,
Adrian

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

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

[Geert Uytterhoeven]

Hi Adrian,

On Tue, 20 May 2025 at 12:05, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Tue, 2025-05-20 at 11:58 +0200, Geert Uytterhoeven wrote:
> > On Tue, 20 May 2025 at 10:38, John Paul Adrian Glaubitz
> > <glaubitz@physik.fu-berlin.de> wrote:
> > > And I also don't understand why this is even an issue. If someone insists
> > > on using 2 bytes alignment, just stick to your old chroot. If you're not
> >
> > What about kernel/userland compatibility?
>
> What about it? This is about userland.

So you don't change the syscall/ioctl/... ABI?

> > > interested in new, "fancy" packages, just don't upgrade or install Debian
> > > Etch or similar. Changing the default alignment does not affect existing
> > > software.
> >
> > What about existing software that is aware the minimum alignment is
> > 2-bytes on m68k?
>
> Can you name some cases? I would love to add these to my list.

Unfortunately not.
Grepping for __mc68000__ may find some.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[John Paul Adrian Glaubitz]

On Tue, 2025-05-20 at 12:09 +0200, Geert Uytterhoeven wrote:
> > > What about kernel/userland compatibility?
> > 
> > What about it? This is about userland.
> 
> So you don't change the syscall/ioctl/... ABI?

I wasn't really planning on changing this. I just want to fix a longstanding
issue which has caused endless hours of wasted developer time to address them.

> > > > interested in new, "fancy" packages, just don't upgrade or install Debian
> > > > Etch or similar. Changing the default alignment does not affect existing
> > > > software.
> > > 
> > > What about existing software that is aware the minimum alignment is
> > > 2-bytes on m68k?
> > 
> > Can you name some cases? I would love to add these to my list.
> 
> Unfortunately not.
> Grepping for __mc68000__ may find some.

Well, we can just fix them on the go. If I see Debian packages FTBFS with 4 bytes
alignment, I can just fix them. So far I have not run into any package that did
not build with 4 bytes alignment but plenty that built with it.

Adrian

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

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

[John Paul Adrian Glaubitz]

Hi Geert,

On Tue, 2025-05-20 at 11:58 +0200, Geert Uytterhoeven wrote:
> > interested in new, "fancy" packages, just don't upgrade or install Debian
> > Etch or similar. Changing the default alignment does not affect existing
> > software.
> 
> What about existing software that is aware the minimum alignment is
> 2-bytes on m68k?

I just remembered that I actually asked the NetBSD people about that and they
said that they didn't run into any problems. In fact, here is a directory with
more than 5500 packages built for NetBSD/m68k with 4 bytes alignment:

https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/m68k/10.0_2024Q3/All/

So, I think we're safe in this regard. There are certainly going to be a few cases
where packages may need to be patched. But I would assume these to be rather rare.

Adrian

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

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

[Finn Thain]

On Tue, 20 May 2025, John Paul Adrian Glaubitz wrote:

> 
> And I really don't want to keep patching stuff forever manually and 
> upload it to Debian unreleased. It's a pure waste of time which is 
> better spent on fixing actual bugs.
> 

As I pointed out years ago, you need to stop wasting effort on packages 
that aren't relevant anymore, due to bloat.

I've also pointed out before that there is plenty of scope for novel tools 
to automatically identify the kind of pointer abuse that you are 
apparently unwilling to work on.

> I really don't understand why people that claim to be interested in the 
> m68k port constantly block any kind of changes that would actually 
> improve the port and prepare it for the future.
> 

And here's another thing you need to understand: there is no future for a 
port that has no porter willing to identify relevant packages and send 
patches upstream.

But, if it's not already dead, you will kill Debian/m68k if you break the 
ABI contract.

Nevermind removing that characteristic which provides it with a unique 
advantage, being a smaller memory and cache footprint.

And before you get upset, I'm not saying this is your fault. The demands 
of your distro apparently don't match the demands of the platform. Nothing 
new there for microcontrollers.

Try to see the big picture. All ports will suffer the same fate as this 
one: fewer users, commercial irrelevance, reluctant contributors and 
bloated packages.

The relevance of m68k is now the way in which we respond to those 
challenges. If the best that any port can hope for is ABI breakage, we've 
failed.

One does not age gracefully by pretending to be young. m68k does not 
contribute anything by becoming the same as every other 32-bit big-endian 
platform.

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

[John Klos]

Hello,

> As I pointed out years ago, you need to stop wasting effort on packages
> that aren't relevant anymore, due to bloat.

There's no real point being made here. Which packages aren't relevant any 
more, due to bloat? Who decides?

> And here's another thing you need to understand: there is no future for a
> port that has no porter willing to identify relevant packages and send
> patches upstream.

This is a non sequitur. Reporting upstream is nice, but a port can exist 
without stuff getting reported upstream.

While Adrian is obviously emotionally committed to improving Linux on 
m68k, the points he makes have reasoning, thought and explanations behind 
them. None of the arguments from you, Finn, make much sense. You're 
talking about irrelevant things and bringing nonsense examples in to the 
discussion. Your examples lack technical merit.

The issue really boils down to this:

Should Linux maintain a 32 bit platform that has alignment issues because 
programmers make bad assumptions?

Your argument is that ABI breakage is death, and that projects and the 
world are better when we tell people to fix their broken code.

I agree that ABI breakage is a huge hurdle. At the same time, the ABI will 
change to fix 32 bit time. Is there any good reason to NOT switch to 32 
bit alignment at the same time the time changes are made? I can't think of 
any reason.

So can we all agree that there's no reason to not change alignment when 
the time changes are done?

Next, I also agree that programmers should not make padding assumptions. 
However, the real world shows us that there are way too many gatekeepers 
who scoff at the idea of supporting anything that's not Arm, amd64, or 
perhaps RISC-V. They don't care if their bad assumptions about floating 
point affect embedded platforms. They don't care if they've assumed that 
nothing of interest ever runs on big endian systems. Heck - they sometimes 
don't even care if things no longer compile or run properly on 32 bit x86!

Dealing with them is tedious. Sometimes a private email to the right 
person in a project leads to a proper fix, and we don't even have to 
publicly talk about the fact that the failure was on m68k, VAX, Alpha, or 
whatever.

I've done enough of this to know that it's far, far better a spend of my 
time to make things work by default where possible, and if not, to 
maintain local patches with an email sent off to good people so the 
gatekeepers can be avoided.

If you think that the work of getting projects to care about edge cases 
isn't hard, then good for you - perhaps you should volunteer to do it. But 
at the same time I've seen you say you don't need and arent interested in 
these fancy new languages and packages, so I can't see you volunteering to 
do it.

So if you're not going to volunteer yourself, then it's not really your 
place to suggest to others that they should be doing it instead of taking 
the easier route, which is to make more things work by default.

> But, if it's not already dead, you will kill Debian/m68k if you break the
> ABI contract.

It's frustrating that you'd write this.

Are there so few fans of m68k that this will kill Debian/m68k? If so, then 
the 64 bit time change will kill Debian/m68k, and there's nothing anyone 
can do about it. So are you saying that the death of Debian/m68k is 
inevitable, and that we should all just give up? Anyone who still wants to 
run a modern OS on m68k hardware can still run NetBSD, after all. Right?

Or maybe this WON'T kill Debian/m68k. And if it won't, then making two ABI 
changes at the same time is no different than making one. Right? So why 
not make the default alignment for m68k fit what programmers, who we all 
agree really shouldn't be assuming, assume for 32 bit so more things Just 
Work?

I see absolutely no compelling reason given by you or anyone else about 
why this shouldn't be done aside from ABI change, and if if the ABI is 
about to change for time, then that reason becomes moot, doesn't it?

Or do you or anyone else have a reason why it's not moot?

> Nevermind removing that characteristic which provides it with a unique
> advantage, being a smaller memory and cache footprint.

This is ridiculous handwaving.

If the memory footprint of software goes up enough to matter because of 32 
bit instead of 16 bit alignment, then perhaps someone should tell people 
running the NetBSD/sun2 port. The very latest NetBSD runs on m68010 
systems with actual 16 bit data busses in 4 megabytes of memory with 32 
bit alignment. Think about all the memory they could save!

Ok. That was a bit snarky, but do you really expect anyone to take this 
seriously?

Likewise, do you really think that the overhead of unaligned access is 
outweighed by the fact that more stuff fits in the cache? Seriously?

> Try to see the big picture. All ports will suffer the same fate as this
> one: fewer users, commercial irrelevance, reluctant contributors and
> bloated packages.

What does any of this have to do with fixing alignment on m68k?

> The relevance of m68k is now the way in which we respond to those
> challenges. If the best that any port can hope for is ABI breakage, we've
> failed.

Are you here advocating for the termination of Debian/m68k? Or are you 
saying that alignment shouldn't be updated, and time shouldn't be updated? 
I really don't understand what you're suggesting.

> One does not age gracefully by pretending to be young. m68k does not
> contribute anything by becoming the same as every other 32-bit big-endian
> platform.

This is nonsense. The natural alignment for m68020, m68030, m68040, m68060 
is 32 bit. That Linux didn't follow the SVR4 spec for ELF was an error.

I really want to know:

Who gets to make the call about whether or not the change is made?

John Klos

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

[Finn Thain]

On Wed, 21 May 2025, John Klos wrote:

> > As I pointed out years ago, you need to stop wasting effort on 
> > packages that aren't relevant anymore, due to bloat.
> 
> There's no real point being made here. Which packages aren't relevant 
> any more, due to bloat? Who decides?
> 

Users do. I've said so several times.
https://lists.debian.org/debian-68k/2023/08/msg00023.html
https://lists.debian.org/debian-68k/2024/10/msg00024.html
https://lists.debian.org/debian-68k/2024/11/msg00019.html

> > And here's another thing you need to understand: there is no future 
> > for a port that has no porter willing to identify relevant packages 
> > and send patches upstream.
> 
> This is a non sequitur. Reporting upstream is nice, but a port can exist 
> without stuff getting reported upstream.
> 
> While Adrian is obviously emotionally committed to improving Linux on 
> m68k, the points he makes have reasoning, thought and explanations 
> behind them. None of the arguments from you, Finn, make much sense. 
> You're talking about irrelevant things and bringing nonsense examples in 
> to the discussion. Your examples lack technical merit.
> 

Perhaps you can show me the technical shortcomings of the patch I sent to 
the python project?

> The issue really boils down to this:
> 
> Should Linux maintain a 32 bit platform that has alignment issues 
> because programmers make bad assumptions?
> 
> Your argument is that ABI breakage is death, and that projects and the 
> world are better when we tell people to fix their broken code.
> 

No, that's not what I said.

> I agree that ABI breakage is a huge hurdle. At the same time, the ABI 
> will change to fix 32 bit time. Is there any good reason to NOT switch 
> to 32 bit alignment at the same time the time changes are made? I can't 
> think of any reason.
> 
> So can we all agree that there's no reason to not change alignment when 
> the time changes are done?
> 

We've been over that before too:
https://lists.debian.org/debian-68k/2023/08/msg00023.html

> Next, I also agree that programmers should not make padding assumptions. 
> However, the real world shows us that there are way too many gatekeepers 
> who scoff at the idea of supporting anything that's not Arm, amd64, or 
> perhaps RISC-V. They don't care if their bad assumptions about floating 
> point affect embedded platforms. They don't care if they've assumed that 
> nothing of interest ever runs on big endian systems. Heck - they 
> sometimes don't even care if things no longer compile or run properly on 
> 32 bit x86!
> 
> Dealing with them is tedious. Sometimes a private email to the right 
> person in a project leads to a proper fix, and we don't even have to 
> publicly talk about the fact that the failure was on m68k, VAX, Alpha, 
> or whatever.
> 
> I've done enough of this to know that it's far, far better a spend of my 
> time to make things work by default where possible, and if not, to 
> maintain local patches with an email sent off to good people so the 
> gatekeepers can be avoided.
> 
> If you think that the work of getting projects to care about edge cases 
> isn't hard, then good for you - perhaps you should volunteer to do it. 

I did that already:
https://lists.debian.org/debian-68k/2024/10/msg00042.html

> But at the same time I've seen you say you don't need and arent 
> interested in these fancy new languages and packages, so I can't see you 
> volunteering to do it.
> 
> So if you're not going to volunteer yourself, then it's not really your 
> place to suggest to others that they should be doing it instead of 
> taking the easier route, which is to make more things work by default.
> 
> > But, if it's not already dead, you will kill Debian/m68k if you break 
> > the ABI contract.
> 
> It's frustrating that you'd write this.
> 
> Are there so few fans of m68k that this will kill Debian/m68k?

Once the ABI fragments, there is no "Linux/m68k" any longer. There are 
isolated groups of users/developers with limited ability to collaborate 
effectively.

> If so, then the 64 bit time change will kill Debian/m68k, and there's 
> nothing anyone can do about it. So are you saying that the death of 
> Debian/m68k is inevitable, and that we should all just give up? Anyone 
> who still wants to run a modern OS on m68k hardware can still run 
> NetBSD, after all. Right?
> 
> Or maybe this WON'T kill Debian/m68k. And if it won't, then making two 
> ABI changes at the same time is no different than making one. Right? So 
> why not make the default alignment for m68k fit what programmers, who we 
> all agree really shouldn't be assuming, assume for 32 bit so more things 
> Just Work?
> 
> I see absolutely no compelling reason given by you or anyone else about 
> why this shouldn't be done aside from ABI change, and if if the ABI is 
> about to change for time, then that reason becomes moot, doesn't it?
> 
> Or do you or anyone else have a reason why it's not moot?
> 

As I've said, I'm okay with a Gentoo/m68k profile for ABI experimentation 
as long as the default profile tracks the upstream toolchain: 
https://lists.debian.org/debian-68k/2024/10/msg00045.html

> > Nevermind removing that characteristic which provides it with a unique 
> > advantage, being a smaller memory and cache footprint.
> 
> This is ridiculous handwaving.
> 
> If the memory footprint of software goes up enough to matter because of 
> 32 bit instead of 16 bit alignment, then perhaps someone should tell 
> people running the NetBSD/sun2 port. The very latest NetBSD runs on 
> m68010 systems with actual 16 bit data busses in 4 megabytes of memory 
> with 32 bit alignment. Think about all the memory they could save!
> 
> Ok. That was a bit snarky, but do you really expect anyone to take this 
> seriously?
> 

Well, your handwaving is no more convincing than mine. Measurements are 
welcome, though it's hard to know which hardware designs to measure.

> Likewise, do you really think that the overhead of unaligned access is 
> outweighed by the fact that more stuff fits in the cache? Seriously?
> 

Yes, some of my 68030 systems have 16-bit data busses.

As for the ones with 32-bit busses, I'd expect that two cache accesses are 
generally faster than a long-word-aligned RAM access, though you may be 
right about those algorithms that miss the cache.

BTW, my Apple Workgroup Server 95 has 512 KB of L2 cache. If I can get 
Linux to run on it, I think it might provide some interesting 
measurements.

> > Try to see the big picture. All ports will suffer the same fate as 
> > this one: fewer users, commercial irrelevance, reluctant contributors 
> > and bloated packages.
> 
> What does any of this have to do with fixing alignment on m68k?
> 
> > The relevance of m68k is now the way in which we respond to those 
> > challenges. If the best that any port can hope for is ABI breakage, 
> > we've failed.
> 
> Are you here advocating for the termination of Debian/m68k? Or are you 
> saying that alignment shouldn't be updated, and time shouldn't be 
> updated? I really don't understand what you're suggesting.
> 
> > One does not age gracefully by pretending to be young. m68k does not 
> > contribute anything by becoming the same as every other 32-bit 
> > big-endian platform.
> 
> This is nonsense. 

It is the main reason why porting to m68k leads to better code.

> The natural alignment for m68020, m68030, m68040, m68060 is 32 bit. That 
> Linux didn't follow the SVR4 spec for ELF was an error.
> 
> I really want to know:
> 
> Who gets to make the call about whether or not the change is made?
> 

Those with the time and skills to write the patches and the ability to 
push them upstream to all the affected projects. Same as always.

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

[Finn Thain]

On Wed, 21 May 2025, I wrote:

> 
> On Wed, 21 May 2025, John Klos wrote:
> 
> > Likewise, do you really think that the overhead of unaligned access is 
> > outweighed by the fact that more stuff fits in the cache? Seriously?
> > 
> 
> Yes, some of my 68030 systems have 16-bit data busses.
> 

For the record, the user manuals say the entries in the 68020 and 68030 
caches are long-words. So a 16-bit data bus would be a liability for 
accesses involving the caches, and John's probably right about overhead.

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

[Finn Thain]

On Wed, 21 May 2025, John Klos wrote:

> 
> But at the same time I've seen you say you don't need and arent 
> interested in these fancy new languages and packages, so I can't see you 
> volunteering to do it.
> 
> So if you're not going to volunteer yourself, then it's not really your 
> place to suggest to others that they should be doing it instead of 
> taking the easier route, which is to make more things work by default.
> 

I won't volunteer if the plan is to break the ABI so you can convert your 
Quadra from C to Rust because you're afraid of NULL pointers. Same goes 
for running bytecode in an Openjdk VM running in a QEMU VM.

I am actively disinterested in that kind of trade-off because the ABI 
churn would impact both users and upstream developers, many of whom will 
receive zero benefit.

Of course, the ABI we have isn't perfect and I'm not against people 
designing a better one, that will be stable for another 30 years. Though 
that is an ambitious undertaking for an under-resourced project.

For example, I doubt that we would ever have gained a TLS implementation 
if had been left up to volunteers. There just aren't enough of us.

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

[John Paul Adrian Glaubitz]

Hello John,

thank you so much for your very elaborate and convincing reply. You have
formulated this way better than me and collected all the important points
that made me come to my wish to change the default alignment to 4 bytes.

I just want to add two more comments below.

On Wed, 2025-05-21 at 01:59 +0000, John Klos wrote:
> 
> > One does not age gracefully by pretending to be young. m68k does not
> > contribute anything by becoming the same as every other 32-bit big-endian
> > platform.
> 
> This is nonsense. The natural alignment for m68020, m68030, m68040, m68060 
> is 32 bit. That Linux didn't follow the SVR4 spec for ELF was an error.

Exactly. I actually went to the library to scan the only copy of the SysV ABI
I could find in Germany and put it up in the Debian Wiki to help foster the
discussion.

> I really want to know:
> 
> Who gets to make the call about whether or not the change is made?

It should be the people who maintain the distribution.

Adrian

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

Re: Debian subset suitable for m68k (was: Tuple and changes for m68k with -malign-int)

[Eero Tamminen]

Hi John,

On 21.5.2025 4.59, John Klos wrote:
>> As I pointed out years ago, you need to stop wasting effort on packages
>> that aren't relevant anymore, due to bloat.
> 
> There's no real point being made here. Which packages aren't relevant 
> any more, due to bloat? Who decides?

Decision part is IMHO rather obvious, it should be both users and 
maintainers together.

It's good for maintainers to ask users for feedback on what matters on 
them, so that effort is not wasted on something that nobody uses.  And 
also to ask help if some task is larger, to see whether there's enough 
interest (= help available) to make that effort actually worthwhile. If 
not, what's the point of maintaining something nobody cares (enough)?

So next question is what are the best ways to reach users and get their 
feedback?

Package statistics, bug reports and just asking on the mailing list(s) 
are first things that come to my mind, but others may have other 
suggestions.

So to start, here are the things that are, and are not, relevant for me 
_on m68k_.  I.e. _personal_ opinions. First some general principles, and 
then few examples.


Relevant
--------

Base system, compilers, interpreters, misc tools, some graphics, and 
things shared between niche/retro communities (like m68k) in general.

In my case, for example:
- Kernel
- Busybox
- Gcc
- G++
- Lua
- Python
- La/TeX
- SDL1
- ScummVM
- Wired networking
- w3m, links, lynx etc
- Small niche windowing systems
- Slimmed-down Debian essentials


Not relevant
------------

Modern corporate backed software, and anything needing encryption or 
GPUs supporting GLES2+, I get enough of those on x86 Linux. They are too 
slow / large for m68k platform, and frankly boring, all something I try 
to avoid in my hobbies. :-)

For example:
- Java & C#
- LibreOffice
- Chrome/ium, Firefox, Webkit
- Modern desktop environments (KDE, Gnome...)
- libSDL v2 & v3, and things depending on them
- Wireless & VPN support
- Virtualization


Potentially relevant
--------------------

Some of the new tech, especially when it relates to smaller setups and 
base system, and more lightweight GUI apps, might also be of interest at 
some point:
- Wayland / Weston
- Golang
- Rust, Zig
- Abiword, Gnumeric, Evince (non-Gnome versions)
- LyX (LaTeX GUI)


Any thoughts on the above principles?


	- Eero

Re: Debian subset suitable for m68k (was: Tuple and changes for m68k with -malign-int)

[John Paul Adrian Glaubitz]

Hello Eero,

> On May 21, 2025, at 4:16 PM, Eero Tamminen <oak@helsinkinet.fi> wrote:
> 
> So to start, here are the things that are, and are not, relevant for me _on m68k_.  I.e. _personal_ opinions. First some general principles, and then few examples.
> 
> 
> Relevant
> --------
> 
> Base system, compilers, interpreters, misc tools, some graphics, and things shared between niche/retro communities (like m68k) in general.
> 
> In my case, for example:
> - Kernel
> - Busybox
> - Gcc
> - G++
> - Lua
> - Python
> - La/TeX
> - SDL1
> - ScummVM
> - Wired networking
> - w3m, links, lynx etc
> - Small niche windowing systems
> - Slimmed-down Debian essentials
> 
> 
> Not relevant
> ------------
> 
> Modern corporate backed software, and anything needing encryption or GPUs supporting GLES2+, I get enough of those on x86 Linux. They are too slow / large for m68k platform, and frankly boring, all something I try to avoid in my hobbies. :-)
> 
> For example:
> - Java & C#
> - LibreOffice
> - Chrome/ium, Firefox, Webkit
> - Modern desktop environments (KDE, Gnome...)
> - libSDL v2 & v3, and things depending on them
> - Wireless & VPN support
> - Virtualization
> 
> 
> Potentially relevant
> --------------------
> 
> Some of the new tech, especially when it relates to smaller setups and base system, and more lightweight GUI apps, might also be of interest at some point:
> - Wayland / Weston
> - Golang
> - Rust, Zig
> - Abiword, Gnumeric, Evince (non-Gnome versions)
> - LyX (LaTeX GUI)
> 
> 
> Any thoughts on the above principles?
> 

The problem is that you assume that we can easily build and maintain a subset of Debian packages without investing a lot of time and effort.

However, I do not intend to maintain a custom version of Debian. I want to build the vanilla version of Debian unstable because I do neither have the time nor the resources to roll my own version of Debian.

And using vanilla Debian unstable means having to build all of these packages that you are trying to avoid because you think they’re bloated or useless.

And, as for Rust, an increasing number of Python packages such as python-cryptography embed Rust code, so the decision whether we should support Rust or not has already been made.

If you think it’s worthwhile to maintain a custom Linux distribution for m68k, you are free to do that. However, it’s not the work I am interested personally.

Adrian

Re: Debian subset suitable for m68k (was: Tuple and changes for m68k with -malign-int)

[Eero Tamminen]

Hi,

On 21.5.2025 20.54, John Paul Adrian Glaubitz wrote:
>> On May 21, 2025, at 4:16 PM, Eero Tamminen <oak@helsinkinet.fi> wrote:
>>
>> So to start, here are the things that are, and are not, relevant for me _on m68k_.  I.e. _personal_ opinions. First some general principles, and then few examples.
...
>> Any thoughts on the above principles?
> 
> The problem is that you assume that we can easily build and maintain a subset of Debian packages without investing a lot of time and effort.

I have no clue how that works, so my naive thought was that one could 
just supply some kind of a package name "skiplist", and builders would 
skip packages in that.

> However, I do not intend to maintain a custom version of Debian. I want to build the vanilla version of Debian unstable because I do neither have the time nor the resources to roll my own version of Debian.
 >
> And using vanilla Debian unstable means having to build all of these packages that you are trying to avoid because you think they’re bloated or useless.

The idea wasn't to customize Debian or its packages, just not (even try 
to) build some of the packages for the m68k package repo.

Is there some documentation on why it won't work?

---

Support for such list seems rather useful feature for the ports 
architectures, to skip packages that won't build as-is, or with trivial 
fixes, and for which nobody has declared interest (so that there would 
be a motive to fix non-trivial issues with them).

As to how that would work in practice, I would imagine that "skiplist" 
provided for builders would need to include also all packages that 
depend from given non-desirable package => there need to be some helper 
scripts to maintain it.

Those helper scripts could generate full "skiplist" from hand-maintained 
smaller one, add everything depending from them, and check that list 
against a hand-maintained whitelist, to verify that deps haven't changed 
so that a package that somebody actually wants to use on m68k, would be 
skipped.


> And, as for Rust, an increasing number of Python packages such as python-cryptography embed Rust code, so the decision whether we should support Rust or not has already been made.

Right, quite a lot of packages depends on that, and even more on Rusted 
librsvg2.

While package dependencies, especially build ones, can quickly get out 
of hand, scripting I discussed above, would help in pointing out all 
implications of dropping or including specific packages.  I.e. provide 
full facts for discussion on whether to drop or include specific (e.g. 
language) package for a m68k port subset.


	- Eero

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

[Geert Uytterhoeven]

Hi John,

On Wed, 21 May 2025 at 04:15, John Klos <john@klos.com> wrote:
> Should Linux maintain a 32 bit platform that has alignment issues because
> programmers make bad assumptions?

Linux (the kernel) does maintain it, and bug fixes are backported
to stable trees.  The upstream kernel (outside the arch/m68k dir)
has no problem fixing whatever alignment issues that pop up.

> Your argument is that ABI breakage is death, and that projects and the
> world are better when we tell people to fix their broken code.

"we don't break user space" is the #1 rule in the kernel[1].

> I agree that ABI breakage is a huge hurdle. At the same time, the ABI will
> change to fix 32 bit time. Is there any good reason to NOT switch to 32
> bit alignment at the same time the time changes are made? I can't think of
> any reason.
>
> So can we all agree that there's no reason to not change alignment when
> the time changes are done?

According to Andeas, here is no change to be made for 64-bit time_t[2].

[1] https://lore.kernel.org/all/CAHk-=wg-6jYZ=bJWdyBR=n8QOfwHTZZdzSUUPgFW+NGCV-pe2g@mail.gmail.com
[2] https://lore.kernel.org/all/87plff8p9w.fsf@igel.home

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[John Paul Adrian Glaubitz]

Hi Geert,

On Tue, 2025-06-17 at 09:02 +0200, Geert Uytterhoeven wrote:
> On Wed, 21 May 2025 at 04:15, John Klos <john@klos.com> wrote:
> > Should Linux maintain a 32 bit platform that has alignment issues because
> > programmers make bad assumptions?
> 
> Linux (the kernel) does maintain it, and bug fixes are backported
> to stable trees.  The upstream kernel (outside the arch/m68k dir)
> has no problem fixing whatever alignment issues that pop up.

This might change in the future when Rust code becomes more dominant in the kernel.

What's going to happen when Rust code becomes mandatory in key parts of the kernel
and then we're unable to build it because we insisted on keeping the 2 byte ABI?

> > Your argument is that ABI breakage is death, and that projects and the
> > world are better when we tell people to fix their broken code.
> 
> "we don't break user space" is the #1 rule in the kernel[1].

Except when we do: https://lwn.net/Articles/605607/ ;-)

> > I agree that ABI breakage is a huge hurdle. At the same time, the ABI will
> > change to fix 32 bit time. Is there any good reason to NOT switch to 32
> > bit alignment at the same time the time changes are made? I can't think of
> > any reason.
> > 
> > So can we all agree that there's no reason to not change alignment when
> > the time changes are done?
> 
> According to Andeas, here is no change to be made for 64-bit time_t[2].

That's not the question to ask though but rather whether the shift to 64-bit
time_t changed the ABI and according to the analysis made at Debian, it did [1].

Adrian

> [1] https://wiki.debian.org/ReleaseGoals/64bit-time

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

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

[Geert Uytterhoeven]

Hi Adrian,

On Tue, 17 Jun 2025 at 09:25, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Tue, 2025-06-17 at 09:02 +0200, Geert Uytterhoeven wrote:
> > On Wed, 21 May 2025 at 04:15, John Klos <john@klos.com> wrote:
> > > Should Linux maintain a 32 bit platform that has alignment issues because
> > > programmers make bad assumptions?
> >
> > Linux (the kernel) does maintain it, and bug fixes are backported
> > to stable trees.  The upstream kernel (outside the arch/m68k dir)
> > has no problem fixing whatever alignment issues that pop up.
>
> This might change in the future when Rust code becomes more dominant in the kernel.
>
> What's going to happen when Rust code becomes mandatory in key parts of the kernel
> and then we're unable to build it because we insisted on keeping the 2 byte ABI?

We fix Rust? ;-)

Is this a Rust issue, or an LLVM issue?
In case of the latter, how does llvm-mos handle this?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[John Paul Adrian Glaubitz]

On Tue, 2025-06-17 at 09:40 +0200, Geert Uytterhoeven wrote:
> > What's going to happen when Rust code becomes mandatory in key parts of the kernel
> > and then we're unable to build it because we insisted on keeping the 2 byte ABI?
> 
> We fix Rust? ;-)

What's keeping us from creating an ABI v2 using either e_ident or e_flags from the ELF
header so that we can fix also all the other packages that don't work like Javascript?

If MIPS can have a plethora of updated ABIs and even POWER got an ELF ABI v2, why should
that not be possible on m68k?

> Is this a Rust issue, or an LLVM issue?

https://github.com/M680x0/M680x0-mono-repo/issues/10

> In case of the latter, how does llvm-mos handle this?

llvm-mos does not build natively the 6502, so this is irrelevant.

Adrian

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

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

[Geert Uytterhoeven]

Hi Adrian,

On Tue, 17 Jun 2025 at 11:48, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Tue, 2025-06-17 at 09:40 +0200, Geert Uytterhoeven wrote:
> > > What's going to happen when Rust code becomes mandatory in key parts of the kernel
> > > and then we're unable to build it because we insisted on keeping the 2 byte ABI?
> >
> > We fix Rust? ;-)
>
> What's keeping us from creating an ABI v2 using either e_ident or e_flags from the ELF
> header so that we can fix also all the other packages that don't work like Javascript?
>
> If MIPS can have a plethora of updated ABIs and even POWER got an ELF ABI v2, why should
> that not be possible on m68k?

IBM annual gross profit for 2024 was $35.552B.

> > Is this a Rust issue, or an LLVM issue?
>
> https://github.com/M680x0/M680x0-mono-repo/issues/10

So you mean it's an LLVM issue.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[John Paul Adrian Glaubitz]

On Tue, 2025-06-17 at 11:59 +0200, Geert Uytterhoeven wrote:
> > What's keeping us from creating an ABI v2 using either e_ident or e_flags from the ELF
> > header so that we can fix also all the other packages that don't work like Javascript?
> > 
> > If MIPS can have a plethora of updated ABIs and even POWER got an ELF ABI v2, why should
> > that not be possible on m68k?
> 
> IBM annual gross profit for 2024 was $35.552B.

I'm not sure how this is relevant at all. What is the gross profit of the NetBSD organization?

> > > Is this a Rust issue, or an LLVM issue?
> > 
> > https://github.com/M680x0/M680x0-mono-repo/issues/10
> 
> So you mean it's an LLVM issue.

It's an issue on many projects that use things like tagged pointers etc.

Adrian

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

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

[Geert Uytterhoeven]

Hi Adrian,

On Tue, 17 Jun 2025 at 12:13, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Tue, 2025-06-17 at 11:59 +0200, Geert Uytterhoeven wrote:
> > > What's keeping us from creating an ABI v2 using either e_ident or e_flags from the ELF
> > > header so that we can fix also all the other packages that don't work like Javascript?
> > >
> > > If MIPS can have a plethora of updated ABIs and even POWER got an ELF ABI v2, why should
> > > that not be possible on m68k?
> >
> > IBM annual gross profit for 2024 was $35.552B.
>
> I'm not sure how this is relevant at all. What is the gross profit of the NetBSD organization?

IOW, you can have plenty of ABIs, if you have the manpower to create
and maintain them.

> > > > Is this a Rust issue, or an LLVM issue?
> > >
> > > https://github.com/M680x0/M680x0-mono-repo/issues/10
> >
> > So you mean it's an LLVM issue.
>
> It's an issue on many projects that use things like tagged pointers etc.

I know.  If you want to tag pointers, it is your responsibility to use
unused bits (Hi Apple 24-bit).  When using the low bit(s) for tagging,
you have to make sure the objects you are pointing to are sufficiently
aligned. BTW, how does LLVM tag pointers to chars?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[John Paul Adrian Glaubitz]

On Tue, 2025-06-17 at 13:21 +0200, Geert Uytterhoeven wrote:
> > I'm not sure how this is relevant at all. What is the gross profit of the NetBSD organization?
> 
> IOW, you can have plenty of ABIs, if you have the manpower to create
> and maintain them.

Both Debian and Gentoo want to maintain the 4 bytes alignment ABI in the long term.

I don't think there is a point to continue to maintain the 2 bytes alignment ABI.

For whom would we do that?

> > > > > Is this a Rust issue, or an LLVM issue?
> > > > 
> > > > https://github.com/M680x0/M680x0-mono-repo/issues/10
> > > 
> > > So you mean it's an LLVM issue.
> > 
> > It's an issue on many projects that use things like tagged pointers etc.
> 
> I know.  If you want to tag pointers, it is your responsibility to use
> unused bits (Hi Apple 24-bit).  When using the low bit(s) for tagging,
> you have to make sure the objects you are pointing to are sufficiently
> aligned. BTW, how does LLVM tag pointers to chars?

I don't know. I'm not an expert on the LLVM codebase even though I made some
contributions. If you know how to address this issue I'm curious to hear about
the fix.

Adrian

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

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

[Finn Thain]

On Tue, 20 May 2025, John Paul Adrian Glaubitz wrote:

> On Tue, 2025-05-20 at 07:59 +1000, Finn Thain wrote:
> > On Mon, 19 May 2025, John Paul Adrian Glaubitz wrote:
> > 
> > > 
> > > My argument is that Linux/m68k is a pure hobbyist project and anyone 
> > > involved can deal with the changes coming from the alignment change.
> > > 
> > 
> > If hobbyists can deal with ABI breakage, they can certainly deal with the 
> > longstanding lack of fancy toolchains and toolkits*.
> 
> Being able to build the build dependencies of cmake or parts of GCC such
> as gccgo is not something I would consider "fancy".

Qt is an optional dependency of cmake, subject to USE=gui on Gentoo, as it 
should be. If that dep is required by Debian, that's a distro problem, not 
an ABI problem.

As for gccgo, has that ever worked on m68k?

> Furthermore, more and more packages are being ported to Rust which means 
> m68k will either die a long death or have to switch to 4 bytes 
> alignment.
> 

Other language runtimes work fine on the m68k ABI. Why is Rust special?

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

[John Paul Adrian Glaubitz]

On Tue, 2025-05-20 at 19:39 +1000, Finn Thain wrote:
> Qt is an optional dependency of cmake, subject to USE=gui on Gentoo, as it 
> should be. If that dep is required by Debian, that's a distro problem, not 
> an ABI problem.

I'm talking about Debian, not Gentoo. And as you admit here, you have to
cripple functionality to make it work which is not what I am interested in.

But if you're using Gentoo anyway, I don't understand what you are even
complaining about. As you heard, Gentoo wants to introduce a new tuple for
the change.

Thus, you can continue to use Gentoo with 16-bit alignment just fine and let
anyone else who needs 32-bit alignment move on.

> As for gccgo, has that ever worked on m68k?

Yes.

> > Furthermore, more and more packages are being ported to Rust which means 
> > m68k will either die a long death or have to switch to 4 bytes 
> > alignment.
> > 
> 
> Other language runtimes work fine on the m68k ABI. Why is Rust special?

You mean other languages such as JavaScript, Go, Java, Python and WebKit?

No, they don't work fine on m68k.

Adrian

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

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

[Finn Thain]

On Tue, 20 May 2025, John Paul Adrian Glaubitz wrote:

> > As for gccgo, has that ever worked on m68k?
> 
> Yes.
> 

Why is an ABI change needed to get it to work again?

> > Other language runtimes work fine on the m68k ABI. Why is Rust 
> > special?
> 
> You mean other languages such as JavaScript, Go, Java, Python and 
> WebKit?
> 
> No, they don't work fine on m68k.
> 

Python works -- you patched it yourself! -- it doesn't need a special ABI. 
As for the Java runtime etc. I've never tried to install them on m68k but 
I know they were ported to a variety of ABIs with a variety of alignment 
rules, that do not guarantee natural alignment of integer types.

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

[John Paul Adrian Glaubitz]

On Tue, 2025-05-20 at 19:55 +1000, Finn Thain wrote:
> On Tue, 20 May 2025, John Paul Adrian Glaubitz wrote:
> 
> > > As for gccgo, has that ever worked on m68k?
> > 
> > Yes.
> > 
> 
> Why is an ABI change needed to get it to work again?

Because software changes over time. Qt used to work with 2 bytes alignment
as well when it had less features.

> > > Other language runtimes work fine on the m68k ABI. Why is Rust 
> > > special?
> > 
> > You mean other languages such as JavaScript, Go, Java, Python and 
> > WebKit?
> > 
> > No, they don't work fine on m68k.
> > 
> 
> Python works -- you patched it yourself! -- it doesn't need a special ABI.

Yes, I had to PATCH it. That's the point, Finn.

> As for the Java runtime etc. I've never tried to install them on m68k but 
> I know they were ported to a variety of ABIs with a variety of alignment 
> rules, that do not guarantee natural alignment of integer types.

I see. Since you haven't tested it, it means the bug doesn't exist.

Gotcha.

Adrian

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

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

[Finn Thain]

On Tue, 20 May 2025, John Paul Adrian Glaubitz wrote:

> On Tue, 2025-05-20 at 19:55 +1000, Finn Thain wrote:
> > On Tue, 20 May 2025, John Paul Adrian Glaubitz wrote:
> > 
> > > > As for gccgo, has that ever worked on m68k?
> > > 
> > > Yes.
> > > 
> > 
> > Why is an ABI change needed to get it to work again?
> 
> Because software changes over time. Qt used to work with 2 bytes alignment
> as well when it had less features.
> 
> > > > Other language runtimes work fine on the m68k ABI. Why is Rust 
> > > > special?
> > > 
> > > You mean other languages such as JavaScript, Go, Java, Python and 
> > > WebKit?
> > > 
> > > No, they don't work fine on m68k.
> > > 
> > 
> > Python works -- you patched it yourself! -- it doesn't need a special ABI.
> 
> Yes, I had to PATCH it. That's the point, Finn.
> 

Yes, and then you declined to send your patch upstream, and a Debian 
developer picked up my patch instead.

When I worked on this, I discovered that your patch was inadequate, that 
the problem was not the m68k ABI, and that you threw away a good 
opportunity to improve the upstream project.

I'm not talking about improving the m68k experience, I'm talking about 
improving correctness, re-usability, portability and readability of the 
source code upstream.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1087600
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1105110

> > As for the Java runtime etc. I've never tried to install them on m68k but 
> > I know they were ported to a variety of ABIs with a variety of alignment 
> > rules, that do not guarantee natural alignment of integer types.
> 
> I see. Since you haven't tested it, it means the bug doesn't exist.

No it means I never had a need for those languages on m68k. Does a bug 
exist if no-one executes it? How many actual users are there for the 
Debian/m68k JVM, besides Debian porters?

> 
> Gotcha.
> 

I assumed the bug may exist, but when I asked about it, you evaded the 
question.

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

[John Paul Adrian Glaubitz]

On Tue, 2025-05-20 at 21:03 +1000, Finn Thain wrote:
> Yes, and then you declined to send your patch upstream, and a Debian 
> developer picked up my patch instead.
> 
> When I worked on this, I discovered that your patch was inadequate, that 
> the problem was not the m68k ABI, and that you threw away a good 
> opportunity to improve the upstream project.

And, did your patch get merged upstream yet?

https://github.com/python/cpython/pull/127546

It's still open which proves my point. And that's just one of many projects
that are affected by the alignment issue as you can see from my list.

> I'm not talking about improving the m68k experience, I'm talking about 
> improving correctness, re-usability, portability and readability of the 
> source code upstream.

Which ignores the fact that hardly any upstream project cares about these
points. And if this was really about adhering to standards and specs, you
would not ignore the fact that the current ABI used on Linux/m68k violates
the official Unix SysV ELF ABI from 1990(!).

> > > As for the Java runtime etc. I've never tried to install them on m68k but 
> > > I know they were ported to a variety of ABIs with a variety of alignment 
> > > rules, that do not guarantee natural alignment of integer types.
> > 
> > I see. Since you haven't tested it, it means the bug doesn't exist.
> 
> No it means I never had a need for those languages on m68k. Does a bug 
> exist if no-one executes it? How many actual users are there for the 
> Debian/m68k JVM, besides Debian porters?

How many actual users in production exist on Debian/m68k except hobbyists?

You're using an argument that works for both sides.

> > 
> > Gotcha.
> > 
> 
> I assumed the bug may exist, but when I asked about it, you evaded the 
> question.

I have created a wiki page for this exact matter:

https://wiki.debian.org/M68k/Alignment

I have posted the link so many times that I don't believe you when you claim
that you have missed it.

Adrian

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

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

[Finn Thain]

On Tue, 20 May 2025, John Paul Adrian Glaubitz wrote:

> On Tue, 2025-05-20 at 21:03 +1000, Finn Thain wrote:
> > Yes, and then you declined to send your patch upstream, and a Debian 
> > developer picked up my patch instead.
> > 
> > When I worked on this, I discovered that your patch was inadequate, 
> > that the problem was not the m68k ABI, and that you threw away a good 
> > opportunity to improve the upstream project.
> 
> And, did your patch get merged upstream yet?
> 
> https://github.com/python/cpython/pull/127546
> 
> It's still open which proves my point. And that's just one of many 
> projects that are affected by the alignment issue as you can see from my 
> list.
> 

You've never reviewed the patch. What is wrong with it?

> > > > I know they were ported to a variety of ABIs with a variety of alignment 
> > > > rules, that do not guarantee natural alignment of integer types.
> > > 
> > > I see. Since you haven't tested it, it means the bug doesn't exist.
> > 
> > No it means I never had a need for those languages on m68k. Does a bug 
> > exist if no-one executes it? How many actual users are there for the 
> > Debian/m68k JVM, besides Debian porters?
> 
> How many actual users in production exist on Debian/m68k except hobbyists?
> 
> You're using an argument that works for both sides.
> 

No, my argument was that you have failed to identify those packages that 
actually need porting.

> > > 
> > > Gotcha.
> > > 
> > 
> > I assumed the bug may exist, but when I asked about it, you evaded the 
> > question.
> 
> I have created a wiki page for this exact matter:
> 
> https://wiki.debian.org/M68k/Alignment
> 

All you have said is that upstream codebases refuse to improve their code 
and that's why an ABI break is needed. This makes no sense at all.

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

[John Klos]

>> There's no real point being made here. Which packages aren't relevant
>> any more, due to bloat? Who decides?
>
> Users do. I've said so several times.
> https://lists.debian.org/debian-68k/2023/08/msg00023.html
> https://lists.debian.org/debian-68k/2024/10/msg00024.html
> https://lists.debian.org/debian-68k/2024/11/msg00019.html

None of those links are relevant to a discussion about software bloat 
and/or who decides if a package is suitable for m68k.


>> You're talking about irrelevant things and bringing nonsense examples in
>> to the discussion. Your examples lack technical merit.
>
> Perhaps you can show me the technical shortcomings of the patch I sent to
> the python project?

"your examples" refers to the "irrelevant things and bringing nonsense 
examples". Your replies that ignore what I'm clearly writing lead me to 
believe you're not engaging in good faith. It was literally in the 
previous sentence.


>> Your argument is that ABI breakage is death, and that projects and the
>> world are better when we tell people to fix their broken code.
>
> No, that's not what I said.

You literally wrote, "But, if it's not already dead, you will kill 
Debian/m68k if you break the ABI contract."


>> So can we all agree that there's no reason to not change alignment when
>> the time changes are done?
>
> We've been over that before too:
> https://lists.debian.org/debian-68k/2023/08/msg00023.html

The discussion at that link offers no reasoning for not doing the 
alignment change.


>> If you think that the work of getting projects to care about edge cases
>> isn't hard, then good for you - perhaps you should volunteer to do it.
>
> I did that already:
> https://lists.debian.org/debian-68k/2024/10/msg00042.html

You half heartedly offered to help with projects that don't accept 
upstream patches. Does this mean you also volunteer to contact them in the 
first place? Have you contacted anyone directly yourself, aside from 
sending an improved patch for python? For instance, have you contacted 
anyone regarding any of the issues with the packages in Adrian's list?


>> Are there so few fans of m68k that this will kill Debian/m68k?
>
> Once the ABI fragments, there is no "Linux/m68k" any longer. There are
> isolated groups of users/developers with limited ability to collaborate
> effectively.

So what do you suppose will happen when the time changes are made?


>> Or do you or anyone else have a reason why it's not moot?
>
> As I've said, I'm okay with a Gentoo/m68k profile for ABI experimentation
> as long as the default profile tracks the upstream toolchain:
> https://lists.debian.org/debian-68k/2024/10/msg00045.html

Does this mean you want / expect the default profile to keep 32 bit time?


> Well, your handwaving is no more convincing than mine. Measurements are
> welcome, though it's hard to know which hardware designs to measure.

Nobody would ever argue that unaligned access comes with no or little cost 
in overhead. They might argue that some modern processors pipeline enough 
that the cost can be folded in to execution, but that's about it. It's a 
well known fact of programming.

Calling my examples handwavy is childish, unless you want to argue that 
the cost of unaligned access is in dispute. Do you want to do that? Do you 
REALLY need measurements of something so well known? Or are you trying to 
deflect?

My example of a low memory / memory constrained system that does very well 
with 32 bit alignment is NetBSD/sun2. I don't have data, but I don't think 
I need data when the very lack of someone saying, "hey - we really need to 
save memory, but we're going to ignore this One Neat Trick in order to 
save more of it" is sufficient.


>> Likewise, do you really think that the overhead of unaligned access is
>> outweighed by the fact that more stuff fits in the cache? Seriously?
>
> Yes, some of my 68030 systems have 16-bit data busses.

Those are two wholly different things.

The point you might be trying to make is that a cache miss on a system 
with a 16 bit bus is more impactful than on a 32 bit bus system. Point 
taken, but that's a rather small edge case (plus you've offered no 
measurements to show the increase in cache misses that comes from 32 bit 
alignment).


> As for the ones with 32-bit busses, I'd expect that two cache accesses are
> generally faster than a long-word-aligned RAM access, though you may be
> right about those algorithms that miss the cache.

Sure, but we're talking about one access, whether cache or memory, versus 
two, cache or memory. The instance where one access to memory happens 
instead of two to cache is very likely insignificant.


> BTW, my Apple Workgroup Server 95 has 512 KB of L2 cache. If I can get
> Linux to run on it, I think it might provide some interesting
> measurements.

Sure, but again, this has little to do with this discussion.


>>> One does not age gracefully by pretending to be young. m68k does not
>>> contribute anything by becoming the same as every other 32-bit
>>> big-endian platform.
>>
>> This is nonsense.
>
> It is the main reason why porting to m68k leads to better code.

I agree with that, but not fixing alignment so that m68k can remain the 
canary in the coal mine isn't a good reason.


Look - there is an incredibly compelling reason to NOT do this change. I 
agree with that wholeheartedly. The reason this thread bothers me so much 
is because instead of discussing the one good reason, discussing possible 
solutions and mitigations of impact, a lot of this discussion has been 
derailed in to irrelevant and sometimes outright intentional diversions.

I really, really would like to see the discussion follow something like:

1) Are we doing this?

Separately, and without constantly going back to (1):

2) If we are going to do this, what will it look like? How will we do it?
    How will we make things easy for users? How will we deal with
    compatibility with old binaries? Will we use a new tuple? How is
    compatibility with binaries using 32 bit time handled, and is what's
    being done there applicable to this change?

John

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

[Finn Thain]

On Wed, 21 May 2025, John Klos wrote:

> >> Your argument is that ABI breakage is death, and that projects and 
> >> the world are better when we tell people to fix their broken code.
> >
> > No, that's not what I said.
> 
> You literally wrote, "But, if it's not already dead, you will kill 
> Debian/m68k if you break the ABI contract."
> 

IMO, if a GNU/Linux distro abandons the upstream ABI, it will die.

IMO, if the upstream maintainers scrap the ABI so that porters can more 
easily port irrelevant packages, then the project loses credibility 
and ABI fragmentation will follow.

IMO, if the ABI is allowed to fragment, collaboration ceases, and the 
project dies.

IMO, if there's no unqiue characteristic to differentiate one port from 
another, one of them will die.

> >
> > Once the ABI fragments, there is no "Linux/m68k" any longer. There are 
> > isolated groups of users/developers with limited ability to 
> > collaborate effectively.
> 
> So what do you suppose will happen when the time changes are made?
> 

It depends on what kind of changes take place. I have not looked into 
this. I need to do some research.