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. :)
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.
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.
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 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.
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.
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?
Thanks for helping to keep m68k alive.
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
- OpenJDK
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.
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.
On August 26, 2023 10:51:39 AM UTC, John Paul Adrian Glaubitz <[email protected]> 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.
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?
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?
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
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.
I think -gnu32 sounds very reasonable.
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?
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.
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.
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".
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?
On Sat, 2023-08-26 at 19:24 +0000, Richard wrote:
On August 26, 2023 10:51:39 AM UTC, John Paul Adrian Glaubitz <[email protected]> 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.
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.
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?
On Sun, Aug 27, 2023 at 11:36 AM James Le Cuirot
<[email protected]> 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"?
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"...
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.
On August 28, 2023 7:00:07 AM UTC, Geert Uytterhoeven <[email protected]> wrote:more warnings and avoid some kinds of trickery.
On Sun, Aug 27, 2023 at 11:36 AM James Le Cuirot ><[email protected]> 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 makingSome projects do accept patches. Yann Collet was even kind enough to fix this
explicit their decisions regarding alignment of shorts? What actual pain >> > does it cause them to accept a patch to make their struct layouts plain? >>
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
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.
Thus.. is there any need to change the kernel ABI?
I don't think this mandates changes to the kernel ABI.
On August 28, 2023 10:57:25 AM UTC, John Paul Adrian Glaubitz <[email protected]> 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.
On August 28, 2023 10:57:25 AM UTC, John Paul Adrian Glaubitz <[email protected]> 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.
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.
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.
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.
After all, we had to change the ABI for TLS support as well, didn't
we?
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.
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?
On August 28, 2023 7:00:07 AM UTC, Geert Uytterhoeven <[email protected]> wrote:
On Sun, Aug 27, 2023 at 11:36 AM James Le Cuirot >><[email protected]> 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 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.
On August 28, 2023 11:26:58 AM UTC, Richard <[email protected]> wrote:
On August 28, 2023 7:00:07 AM UTC, Geert Uytterhoeven <[email protected]> wrote:
On Sun, Aug 27, 2023 at 11:36 AM James Le Cuirot >><[email protected]> 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?
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.
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.
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.
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.
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?
On Mon, 2023-08-28 at 15:17 +0200, Andreas Schwab wrote:Then, in a slightly less than ideal world, errors in FPU emulation
On Aug 28 2023, John Paul Adrian Glaubitz wrote:In an ideal world, I would be testing on real hardware, yes. Unfortunately, even on
The FP failures are most likely the result of the limitations of the FPU emulationNo, you should test on real hardware. Neither ARAnyM nor QEMU comes
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.
close.
my Amiga 4000 with 68060/50 MHz the testsuite would run two weeks or so.
So, any binaries from Debian Potato will still work against glibc 2.38 on m68k?After all, we had to change the ABI for TLS support as well, didn'tNope.
we?
Adrian
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 ;-).
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.
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
[1] https://buildd.debian.org/status/fetch.php?pkg=python3.13&arch=m68k&ver=3.13.0%7Eb1-2&stamp=1715773703&raw=0
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.
[1] https://wiki.debian.org/M68k/Alignment
It correlates with the default in AmigaOS, which was originally
optimized to fit in 256K of RAM.
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.
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...
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.
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.
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.
* 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.
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?
On Mon, 19 May 2025 at 10:18, John Paul Adrian Glaubitz <[email protected]> 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.
[1] https://lwn.net/Articles/605607/
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
My argument is that Linux/m68k is a pure hobbyist project and anyone
involved can deal with the changes coming from the alignment change.
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.
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?
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.
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?
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.
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
On Tue, 20 May 2025 at 10:38, John Paul Adrian Glaubitz <[email protected]> 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?
As for gccgo, has that ever worked on m68k?
Yes.
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.
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.
On Tue, 2025-05-20 at 11:58 +0200, Geert Uytterhoeven wrote:
On Tue, 20 May 2025 at 10:38, John Paul Adrian Glaubitz <[email protected]> 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.
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.
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.
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.
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?
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.
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 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
As I pointed out years ago, you need to stop wasting effort on packages
that aren't relevant anymore, due to bloat.
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.
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.
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?
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.
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?
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.
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
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 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.
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
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
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.
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
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.
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.
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."
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?
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.
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?
On Wed, 21 May 2025 at 04:15, John Klos <[email protected]> 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://wiki.debian.org/ReleaseGoals/64bit-time
On Tue, 2025-06-17 at 09:02 +0200, Geert Uytterhoeven wrote:
On Wed, 21 May 2025 at 04:15, John Klos <[email protected]> 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?
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?
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.
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?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 43:08:05 |
| Calls: | 12,111 |
| Calls today: | 2 |
| Files: | 15,008 |
| Messages: | 6,518,438 |