I don't know about the 64 byte alignment on NetBSD. Maybe it was copied/pasted/modified from amd64? amd64 has a BIGGEST_ALIGNMENT of 64
due to AVX512. Prior to that, I believe amd64 had a BIGGEST_ALIGNMENT
of 32 due to AVX. (These were due to the aligned loads, like _mm256_load_epi32 (32-byte requirement) or _mm512_load_epi32 (64-byte requirement)).
For PowerPC with Altivec, I believe BIGGEST_ALIGNMENT should be 16.
I don't know if __ALTIVEC__ plays a part in BIGGEST_ALIGNMENT. That
is, should BIGGEST_ALIGNMENT be 4 (for int) or 8 (for doubles) unless __ALTIVEC__ is defined; and if __ALTIVEC__ is defined, then
BIGGEST_ALIGNMENT should be 16.
On May 26, 2025, at 8:05 AM, John Paul Adrian Glaubitz <[email protected]> wrote:
Now I'm wondering whether why some types on NetBSD such as double have 8 bytes
alignment on a 32-bit system. Does anyone know the reasoning for that?
Because that’s what is specified in the System V ABI for m68k.
https://m680x0.github.io/ref/sysv-m68k-abi-part1.pdf
See Figure 3-1. “double” and “long double” are explicitly 8-byte aligned.
On May 26, 2025, at 8:05 AM, John Paul Adrian Glaubitz <[email protected]> wrote:
Now I'm wondering whether why some types on NetBSD such as double have 8 bytes
alignment on a 32-bit system. Does anyone know the reasoning for that?
I had to change three offsets:
diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c
index e628b859ef21..5b8ef98565c2 100644
--- a/arch/m68k/kernel/signal.c
+++ b/arch/m68k/kernel/signal.c
@@ -618,11 +618,11 @@ static inline void siginfo_build_tests(void)
BUILD_BUG_ON(offsetof(siginfo_t, si_addr_lsb) != 0x10);
/* _sigfault._addr_bnd */
- BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x12);
- BUILD_BUG_ON(offsetof(siginfo_t, si_upper) != 0x16);
+ BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x14);
+ BUILD_BUG_ON(offsetof(siginfo_t, si_upper) != 0x18);
/* _sigfault._addr_pkey */
- BUILD_BUG_ON(offsetof(siginfo_t, si_pkey) != 0x12);
+ BUILD_BUG_ON(offsetof(siginfo_t, si_pkey) != 0x14);
/* _sigfault._perf */
BUILD_BUG_ON(offsetof(siginfo_t, si_perf_data) != 0x10);
The kernel is booting, so, I suppose it is working :-).
Now, I can't send a patch fixing the offsets like that, as it depends on
the BIGGEST_ALIGNMENT value...
I tried to patch gcc-13 with this BIGGEST_ALIGNMENT set to 64. I am
using buildroot+uclibc-ng on a Coldfire (mcf54418).
Everything build fine, except the kernel:
In function ‘siginfo_build_tests’,
inlined from ‘restore_sigcontext’ at arch/m68k/kernel/signal.c:684:2,
inlined from ‘do_sigreturn’ at arch/m68k/kernel/signal.c:775:9: ././include/linux/compiler_types.h:542:45: error: call to ‘__compiletime_assert_351’ declared with attribute error: BUILD_BUG_ON failed: offsetof(siginfo_t, si_lower) != 0x12
542 | _compiletime_assert(condition, msg,
__compiletime_assert_, __COUNTER__)
| ^ ././include/linux/compiler_types.h:523:25: note: in definition of macro ‘__compiletime_assert’
523 | prefix ## suffix();
\
| ^~~~~~ ././include/linux/compiler_types.h:542:9: note: in expansion of macro ‘_compiletime_assert’
542 | _compiletime_assert(condition, msg,
__compiletime_assert_, __COUNTER__)
| ^~~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:39:37: note: in expansion of macro ‘compiletime_assert’
39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
| ^~~~~~~~~~~~~~~~~~ ./include/linux/build_bug.h:50:9: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
50 | BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
| ^~~~~~~~~~~~~~~~
arch/m68k/kernel/signal.c:621:9: note: in expansion of macro ‘BUILD_BUG_ON’
621 | BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x12);
| ^~~~~~~~~~~~
make[5]: *** [scripts/Makefile.build:207: arch/m68k/kernel/signal.o] Error 1 make[4]: *** [scripts/Makefile.build:465: arch/m68k/kernel] Error 2
make[4]: *** Waiting for unfinished jobs....
This is a 6.14.
Any idea about this ?
Hi,
I'm currently testing enabling 4 bytes alignment and first started looking into
what NetBSD does (gcc/config/m68k/linux.h in the GCC source). Surprisingly, this
is set to 64 and not 32 bits for the largest possible alignment.
The explanation is as follows:
/* No data type wants to be aligned rounder than this.
For m68k/SVR4, some types (doubles for example) are aligned on 8 byte
boundaries */
#undef BIGGEST_ALIGNMENT
#define BIGGEST_ALIGNMENT 64
BIGGEST_ALIGNMENT is what's being toggled with the -malign-int option
in gcc/config/m68k/m68k.h:
/* No data type wants to be aligned rounder than this.
Most published ABIs say that ints should be aligned on 16-bit
boundaries, but CPUs with 32-bit busses get better performance
aligned on 32-bit boundaries. */
#define BIGGEST_ALIGNMENT (TARGET_ALIGN_INT ? 32 : 16)
In order to test GCC on Linux/m68k with 32-bit alignment, I just copied
the definitions from netbsd-elf.h into linux.h above which eventually
failed with:
free(): invalid pointer
during GIMPLE pass: slp ../../../../../src/libstdc++-v3/src/c++17/floating_from_chars.cc: In function 'std::from_chars_result std::from_chars(const char*, const char*, double&, chars_format)':
../../../../../src/libstdc++-v3/src/c++17/floating_from_chars.cc:1243:1: internal compiler error: Aborted
Now I'm wondering whether why some types on NetBSD such as double have 8 bytes
alignment on a 32-bit system. Does anyone know the reasoning for that?
And does libstdc++ have an additional codepath on NetBSD to deal with the largest possible alignment to be 8 bytes so that the error above does not occur?
Or could it just be a result of the ABI mismatch because glibc needs to be patched as well?
On Thu, 2025-06-05 at 08:50 +0200, Jean-Michel Hautbois wrote:
I had to change three offsets:
diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c
index e628b859ef21..5b8ef98565c2 100644
--- a/arch/m68k/kernel/signal.c
+++ b/arch/m68k/kernel/signal.c
@@ -618,11 +618,11 @@ static inline void siginfo_build_tests(void)
BUILD_BUG_ON(offsetof(siginfo_t, si_addr_lsb) != 0x10);
/* _sigfault._addr_bnd */
- BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x12);
- BUILD_BUG_ON(offsetof(siginfo_t, si_upper) != 0x16);
+ BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x14);
+ BUILD_BUG_ON(offsetof(siginfo_t, si_upper) != 0x18);
/* _sigfault._addr_pkey */
- BUILD_BUG_ON(offsetof(siginfo_t, si_pkey) != 0x12);
+ BUILD_BUG_ON(offsetof(siginfo_t, si_pkey) != 0x14);
/* _sigfault._perf */
BUILD_BUG_ON(offsetof(siginfo_t, si_perf_data) != 0x10);
OK, great. This is valuable information.
The kernel is booting, so, I suppose it is working :-).
Now, I can't send a patch fixing the offsets like that, as it depends on the BIGGEST_ALIGNMENT value...
Yes, please send a patch. I don't expect it to be accepted immediately, but it will help us spur a discussion on the necessary changes in the kernel.
Yes, please send a patch. I don't expect it to be accepted immediately, but it will help us spur a discussion on the necessary changes in the kernel.
It will be NAKed, because it would break the ABI.
Thank you for providing solid evidence that changing the default
alignment in the compiler will break the ABI, and is thus unacceptable.
(I wanted to test-compile all uapi headers to find differences, but
ran into many headers not being self-contained, or causing conflicts).
Feel free to start arch/m68k32/ to work around this ;-)
BTW, looking into the history of __ADDR_BND_PKEY_PAD() (which is
overkill on m68k, as __alignof__(void *) = 2, but might still be useful
for anyone wanting to revive CRIS support ;-), I ran into Andreas' explanation why the minimal alignment is still 2 bytes: https://lore.kernel.org/all/[email protected]/.
[1] https://lwn.net/Articles/605607/
Hello Geert,
On Thu, 2025-06-05 at 09:16 +0200, Geert Uytterhoeven wrote:
No problem. We'll carry the patches downstream then. I'm not going to change my mind about this because the alternative would be to just let the port die.Yes, please send a patch. I don't expect it to be accepted immediately, but >>> it will help us spur a discussion on the necessary changes in the kernel. >> It will be NAKed, because it would break the ABI.
Thank you for providing solid evidence that changing the defaultAnd who cares about breaking the ABI in a retro-computing platform except
alignment in the compiler will break the ABI, and is thus unacceptable.
for the few people actively maintaining it? This argument only really makes sense when talking about something that has commercial relevance or a relevant
user base.
(I wanted to test-compile all uapi headers to find differences, butNope, we're just going to carry patches downstream and I'll just ignore people
ran into many headers not being self-contained, or causing conflicts).
Feel free to start arch/m68k32/ to work around this ;-)
that actively want to obstruct fixing a long-time problem on m68k with the weak
argument that it would break Linux binaries from 1993 running on a modern kernel.
This isn't a use case I care about.
BTW, looking into the history of __ADDR_BND_PKEY_PAD() (which isThis post just proves that it's always a bad idea to keep historical burden instead of fixing it.
overkill on m68k, as __alignof__(void *) = 2, but might still be useful
for anyone wanting to revive CRIS support ;-), I ran into Andreas'
explanation why the minimal alignment is still 2 bytes:
https://lore.kernel.org/all/[email protected]/.
Again, can you please bring up a convincing argument why it would be a hard problem to break the ABI for Linux on 40-year-old hardware? And who would be affected by it?
The ABI isn't set in stone and if need to break it to fix fundamental problems,
then be it. They even broke the ABI on a production architecture (s390) back in 2014 [1] and apparently we were all able to move on after this.
Adrian
[1] https://lwn.net/Articles/605607/
Just curious; does not Linux use the processor-specific flagging in the binary that can tell whether it's 16- or 32-bit-aligned (and handle it thereafter)?
NetBSD changed VAX from 1k to 4k pages quite some time ago, and to be able
to use both we added a new id for 4k pages.
file lsls: ELF 64-bit MSB pie executable, SPARC V9, relaxed memory ordering, version 1 (SYSV), dynamically linked, interpreter /libexec/ld.elf_so, for NetBSD 10.99.14, compiler model: medmid, not stripped
readelf -n ls
On Thu, Jun 05, 2025 at 10:49:08AM +0200, Anders Magnusson wrote:
Just curious; does not Linux use the processor-specific flagging in the binary that can tell whether it's 16- or 32-bit-aligned (and handle it thereafter)?
NetBSD changed VAX from 1k to 4k pages quite some time ago, and to be able to use both we added a new id for 4k pages.
Or add an ELF note to all new binaries - we do that on sparc64 to mark
the compiler memory model used and give all binaries w/o the note
(or a note that it is using "medlow") a different VA memory layout (to
keep shared libs in range of the instructions used there, but defeating
most of ASLR).
(I wanted to test-compile all uapi headers to find differences, but
ran into many headers not being self-contained, or causing conflicts).
Feel free to start arch/m68k32/ to work around this ;-)
Nope, we're just going to carry patches downstream and I'll just ignore people that actively want to obstruct fixing a long-time problem on m68k
with the weak argument that it would break Linux binaries from 1993
running on a modern kernel.
This isn't a use case I care about.
BTW, looking into the history of __ADDR_BND_PKEY_PAD() (which is
overkill on m68k, as __alignof__(void *) = 2, but might still be
useful for anyone wanting to revive CRIS support ;-), I ran into
Andreas' explanation why the minimal alignment is still 2 bytes: https://lore.kernel.org/all/[email protected]/.
This post just proves that it's always a bad idea to keep historical
burden instead of fixing it.
Again, can you please bring up a convincing argument why it would be a
hard problem to break the ABI for Linux on 40-year-old hardware? And who would be affected by it?
The ABI isn't set in stone and if need to break it to fix fundamental problems, then be it.
On Thu, 5 Jun 2025 at 12:33, Martin Husemann <[email protected]> wrote:
On Thu, Jun 05, 2025 at 10:49:08AM +0200, Anders Magnusson wrote:
Just curious; does not Linux use the processor-specific flagging in the binary that can tell whether it's 16- or 32-bit-aligned (and handle it thereafter)?
NetBSD changed VAX from 1k to 4k pages quite some time ago, and to be able
to use both we added a new id for 4k pages.
Or add an ELF note to all new binaries - we do that on sparc64 to mark
the compiler memory model used and give all binaries w/o the note
(or a note that it is using "medlow") a different VA memory layout (to
keep shared libs in range of the instructions used there, but defeating most of ASLR).
Op MIPS N32 (EF_MIPS_ABI2), which also uses different syscall numbers.
Then the kernel has to take care of the translation.
Whereas, the ability to use old binaries is proof that we care about rule
#1 don't break userspace.
Having said that, I agree that there is scope for a better ABI. Users/developers will eventually want solutions to the Y2038 problem.
BTW, looking into the history of __ADDR_BND_PKEY_PAD() (which is overkill on m68k, as __alignof__(void *) = 2, but might still be
useful for anyone wanting to revive CRIS support ;-), I ran into Andreas' explanation why the minimal alignment is still 2 bytes: https://lore.kernel.org/all/[email protected]/.
This post just proves that it's always a bad idea to keep historical burden instead of fixing it.
Again, can you please bring up a convincing argument why it would be a hard problem to break the ABI for Linux on 40-year-old hardware? And who would be affected by it?
I think Arnd already answered those questions: https://lore.kernel.org/all/[email protected]/
Moreover, "what's wrong with my idea" is the wrong question. The right question is, "what's wrong with my patches?"
The ABI isn't set in stone and if need to break it to fix fundamental problems, then be it.
Well, that's a value judgement you're free to make regarding your systems. It's easy to find fault in other peoples' systems but it's also pointless. It won't get us closer to a consensus that will hold for another 30 years.
Who is "we"? The official(!) ABI says that pointers are supposed to be aligned
with 4 bytes, not 2 bytes.
On Jun 07 2025, John Paul Adrian Glaubitz wrote:The paper copy of the "System V Application Binary Interface" for 68000
Who is "we"? The official(!) ABI says that pointers are supposed to be alignedNo, that is wrong. The official ABI uses 2 byte alignment.
with 4 bytes, not 2 bytes.
The paper copy of the "System V Application Binary Interface" for 68000
that I have here says that all pointers should be aligned 4 bytes (figure 3-1). Nothing else.
Den 2025-06-07 kl. 13:11, skrev Andreas Schwab:
On Jun 07 2025, Anders Magnusson wrote:
The paper copy of the "System V Application Binary Interface" for 68000 that I have here says that all pointers should be aligned 4 bytes (figure 3-1). Nothing else.And how is that relevant?
Well, were we not discussing the ELF specification for 68k?
[1] https://lore.kernel.org/all/[email protected]/
On Jun 07 2025, John Paul Adrian Glaubitz wrote:
Who is "we"? The official(!) ABI says that pointers are supposed to be aligned
with 4 bytes, not 2 bytes.
No, that is wrong. The official ABI uses 2 byte alignment.
On Jun 07 2025, Anders Magnusson wrote:Well, were we not discussing the ELF specification for 68k?
The paper copy of the "System V Application Binary Interface" for 68000And how is that relevant?
that I have here says that all pointers should be aligned 4 bytes (figure
3-1). Nothing else.
On Jun 07 2025, John Paul Adrian Glaubitz wrote:
On Sat, 2025-06-07 at 11:58 +0200, Andreas Schwab wrote:
On Jun 07 2025, John Paul Adrian Glaubitz wrote:
Who is "we"? The official(!) ABI says that pointers are supposed to be aligned
with 4 bytes, not 2 bytes.
No, that is wrong. The official ABI uses 2 byte alignment.
The official AT&T SysV ABI states that pointers must be aligned with 4 bytes.
If you want to use AT&T System V, you are free to do so. But Linux is
not AT&T System V.
On Jun 07 2025, John Paul Adrian Glaubitz wrote:
On Sat, 2025-06-07 at 17:03 +0200, Andreas Schwab wrote:
On Jun 07 2025, John Paul Adrian Glaubitz wrote:
you cannot change the ABI because that would change the ABI.
That's the fundamental property of an ABI.
Not if the ABI was made-up by yourself ;-).
No, I didn't.
It was very obviously your decision to use 2 byte alignment even though it was against the official SVR4 ABI ;-).
On Sat, 2025-06-07 at 17:03 +0200, Andreas Schwab wrote:
On Jun 07 2025, John Paul Adrian Glaubitz wrote:
you cannot change the ABI because that would change the ABI.
That's the fundamental property of an ABI.
Not if the ABI was made-up by yourself ;-).
It was very obviously your decision to use 2 byte alignment even though it >> was against the official SVR4 ABI ;-).
No, I followed the official ABI.
On Jun 07 2025, John Paul Adrian Glaubitz wrote:
you cannot change the ABI because that would change the ABI.
That's the fundamental property of an ABI.
I've suggested rolling this in to the ABI change that'll address Y2038. I think, although you're not abundantly clear, that you advocate for that change to not be made, too.
On Jun 7, 2025, at 2:58 AM, Andreas Schwab <[email protected]> wrote:
On Jun 07 2025, John Paul Adrian Glaubitz wrote:
Who is "we"? The official(!) ABI says that pointers are supposed to be aligned
with 4 bytes, not 2 bytes.
No, that is wrong. The official ABI uses 2 byte alignment.
https://m680x0.github.io/ref/sysv-m68k-abi-part1.pdf
On Jun 7, 2025, at 2:43 PM, Andreas Schwab <[email protected]> wrote:
On Jun 07 2025, Jason Thorpe wrote:
https://m680x0.github.io/ref/sysv-m68k-abi-part1.pdf
How is that relevant?
On Fri, 2025-06-06 at 20:20 +1000, Finn Thain wrote:
Whereas, the ability to use old binaries is proof that we care about
rule #1 don't break userspace.
Who is "we"?
The official(!) ABI says that pointers are supposed to be aligned with 4 bytes, not 2 bytes. It's the current implementation that violates the
ABI, not what I want to achieve which is make Linux/m68k adhere to the official specification.
Furthermore, we're still talking about a hobbyist platform here which
hasn't been in production use for more than ten years. It doesn't really matter whether we break the ABI or not.
And it's not like there isn't strong case for making this change. As I
have tirelessly explained, the current port with 2 bytes alignment is
simply no longer feasible since an increasing number of packages either require 4 bytes alignment or require Rust.
These include more and more fundamental packages such as coreutils, the kernel or various Python packages such as python-cryptography. It's
simply not an option to continue on the current path as it has become a dead-end.
I don't see the point in maintaining something that becomes increasingly useless because more and more packages are no longer buildable.
On Sat, 7 Jun 2025, John Paul Adrian Glaubitz wrote:
On Fri, 2025-06-06 at 20:20 +1000, Finn Thain wrote:
Whereas, the ability to use old binaries is proof that we care about rule #1 don't break userspace.
Who is "we"?
AFAICT, it's essentially everyone who contributes patches at the userspace interfaces.
8--
Since this thread also hit a non-Linux lists I just want to point
out that we (as in: NetBSD) did not break userland when adapting the
SVR4 ABI including different alignment for ELF.
I just tested it with some original 1994 NetBSD 1.0 / amiga binaries
on an amiga running NetBSD-current as of earlier today.
(...)
So the 1.0 original release a.out binaries still work and a -current
kernel provides the right data (with old alignment and 32bit time_t)
for a stat(2) system call from 1994 using the a.out ABI.
I don't see the point in maintaining something that becomes increasingly useless because more and more packages are no longer buildable.
That's because you still haven't identified those packages in the Debian archive which actually need porting.
On Jun 07 2025, Jason Thorpe wrote:
https://m680x0.github.io/ref/sysv-m68k-abi-part1.pdf
How is that relevant?
Furthermore, we're still talking about a hobbyist platform here which hasn't been in production use for more than ten years. It doesn't really matter whether we break the ABI or not.
By the same argument, since Debian is comprised of volunteers and
hobbyists, it can be ignored by corporate-sponsored organizations, such as the Rust Foundation, and by upstream maintainers employed by for-profit companies. Yet they don't ignore us. Why do you think that is?
And it's not like there isn't strong case for making this change. As I have tirelessly explained, the current port with 2 bytes alignment is simply no longer feasible since an increasing number of packages either require 4 bytes alignment or require Rust.
These include more and more fundamental packages such as coreutils, the kernel or various Python packages such as python-cryptography. It's
simply not an option to continue on the current path as it has become a dead-end.
Every CPU architecture is a dead end. This observation is as old as
Moore's Law.
I don't see the point in maintaining something that becomes increasingly useless because more and more packages are no longer buildable.
That's because you still haven't identified those packages in the Debian archive which actually need porting.
On Sun, 2025-06-08 at 11:10 +1000, Finn Thain wrote:
I don't see the point in maintaining something that becomes
increasingly useless because more and more packages are no longer buildable.
That's because you still haven't identified those packages in the
Debian archive which actually need porting.
Finn, you seriously have to be kidding me. I have created a wiki page
with all the packages in question and I have posted a link to that page multiple times.
See: https://wiki.debian.org/M68k/Alignment
Are you deliberately ignoring that?
There is a clear difference between architectures that are actively used
in production as compared to architectures that are used for hobbyists projects only.
We couldn't push such changes on x86_64, for example, because there is
huge worldwide userbase meaning that introducing such an ABI-breaking
change would come at a huge cost. On m68k, on the other hand, the user
base is so small and insignificant
that the costs for introducing the change are negligible and the profits
for making the change strongly outweigh the disadvantages.
On 6/10/25 5:26 AM, John Paul Adrian Glaubitz wrote:
...As part of that "small and insignificant" user community, I can say that making things too complicated or difficult will be detrimental,
On m68k, on the other hand, the user base is so small and insignificant that the costs for introducing the change are negligible and the profits for making the change strongly outweigh the disadvantages.
...
especially affecting new users.
Look at it from the perspective of a new user today on m68k systems. I
still remember the joy of being able to get a Linux 2.x kernel working
in Debian 3 on an ancient Mac IIci or SE/30. Now as the complexity
grows, I can't do much of anything useful with an old m68k Mac other
than log in (text only), edit a few files and download a few things from
the public Internet. Almost everything related to an end-user's updates
of a Debian or Gentoo distribution has to be done in QEMU or
cross-compiled. Users don't want to be berated or invited to feel bad or
lazy for wanting old things (e.g. mac-fdisk or dump/restore) to continue working on old systems, or for wanting old programs to continue to work. Treating users well, even if they aren't as good at programming as you
are, will make them want to be part of your team, not just part of an insignificant user base of a product that you provide.
As previously stated, NetBSD uses 4 bytes alignment and runs fine even on 68010-based systems. In fact, using a 4 bytes alignment will actually
improve performance as it's the natural alignment the hardware uses.
It will decrease performance if increased alignment means that something that fit earlier into i/d-cache, does not fit any more.
(68030 has 256 bytes, 68040 has 4 KB, and 68060 has 8 KB, of both.)
To get some numbers on this...
if you could provide vmlinuz & System.map files for both (otherwise identical) 2-byte & 4-byte alignment kernel builds, using kernel config here:
https://github.com/hatari/hatari/blob/main/tools/linux/kernel.config
I could measure the perf difference for the whole kernel boot, and if
there are differences, profile what causes those differences.
I'm not sure what you are trying to say here. The fact that your
computer is too slow for modern Linux distributions is unrelated to the alignment discussion.
Sorry, Adrian, but you can't have it both ways. Either you support small systems or you don't. Debian's documentation says of m68k:
This architecture covers Amigas and ATARIs having a Motorola 680x0 processor for x>=2; with MMU. However, the port is still active and available for installation even if not a part of this official stable
release and might be reactivated for future releases.
https://www.debian.org/doc/manuals/debian-faq/compatibility.en.html#arches
There is no mention of fast emulators. Yet that's all you're targeting now.
Fixing pthreads would probably go a long way. That's where we lost about half of our performance.
On Wed, 11 Jun 2025, John Paul Adrian Glaubitz wrote:
I'm not sure what you are trying to say here. The fact that your
computer is too slow for modern Linux distributions is unrelated to the alignment discussion.
Sorry, Adrian, but you can't have it both ways. Either you support small systems or you don't. Debian's documentation says of m68k:
This architecture covers Amigas and ATARIs having a Motorola 680x0
processor for x>=2; with MMU. However, the port is still active and
available for installation even if not a part of this official stable
release and might be reactivated for future releases.
https://www.debian.org/doc/manuals/debian-faq/compatibility.en.html#arches
There is no mention of fast emulators. Yet that's all you're targeting
now.
Debian needs to fix this, so that those users/developers who are
interested in small systems can colaborate effectively without being mislead.
On Jun 12, 2025, at 3:18 AM, John Paul Adrian Glaubitz <[email protected]> wrote:
It's also absurd that you think that switching the alignment to 4 bytes will make the port considerably slower when the contrary is the case and NetBSD developers on this thread have explained several times that they don't have any issues with 4 bytes alignment. Heck, even Amiga Unix uses 4 bytes alignment.
Thanks for your great hard work and efforts to mantain the various and now considered exotic architectures running Debian, Adrian!
On Wed, 2025-06-11 at 18:32 +0300, Eero Tamminen wrote:
It will decrease performance if increased alignment means that something
that fit earlier into i/d-cache, does not fit any more.
»Control whether GCC aligns int, long, long long, float, double, and long double
variables on a 32-bit boundary (-malign-int) or a 16-bit boundary (-mno-align-int).
Aligning variables on 32-bit boundaries produces code that runs somewhat faster on
processors with 32-bit busses at the expense of more memory.«
To get some numbers on this...
if you could provide vmlinuz & System.map files for both (otherwise
identical) 2-byte & 4-byte alignment kernel builds, using kernel config
here:
https://github.com/hatari/hatari/blob/main/tools/linux/kernel.config
I could measure the perf difference for the whole kernel boot, and if
there are differences, profile what causes those differences.
But anyway, as I have said before, I am not going to change my mind on this and I'm already working on it. If you prefer maintaining a Linux port with
2 bytes alignment, you are free to do so. But please don't expect me to waste my time on it.
And therein lies the rub -- to identify those workloads which should be measured and to afford each one a suitable weight in your decision making.
That's why this was always political.
Thanks for your great hard work and efforts to mantain the various and now considered exotic architectures running Debian, Adrian!
On Thu, 12 Jun 2025, John Paul Adrian Glaubitz wrote:
On Wed, 2025-06-11 at 20:16 -0700, Stefan Reinauer wrote:
Fixing pthreads would probably go a long way. That's where we lost
about half of our performance.
This may be accurate, but I'm again not sure how this is related to the discussion we're having.
It's related because such changes could impact all of the C libraries and compiler toolchains that you wish to port. So it's an example of a burden created by package archive growth. https://lists.debian.org/debian-68k/2025/06/msg00048.html
It's also related because such an enhancement may involve an ABI break. That's why I mentioned threading a week ago. https://lists.debian.org/debian-68k/2025/06/msg00018.html
Finn accuses me that I deliberately slow down Linux on m68k when all I
do is continue to maintain vanilla Debian on m68k.
Citation needed. What I have said is, Debian is bloated (in part) because
of its dependency graph e.g. the cmake dep on Qt, which you defended. https://lists.debian.org/debian-68k/2025/05/msg00038.html
On 13.6.2025 4.36, Finn Thain wrote:
And therein lies the rub -- to identify those workloads which should be measured and to afford each one a suitable weight in your decision making.
It's not just workload affecting the results; compiler version,
optimization options [1], workload & kernel config options and sometimes even unrelated code changes [2], can affect how given instruction
sequence settles into cache.
That's why this was always political.
I'd rather keep things technical and fact-based.
Whatever testing is done, the one wider conclusion that *can* be drawn
from it, is that if there's a noticeable performance difference, such differences are possible also in other workloads.
(Very large difference could indicate also functional issues, e.g. bug
in given compiler build code generation. That's why it's important to
have good tooling for pinpointing what exactly is causing the difference.)
"The official(!) ABI"...
Official according to what and to who?
There are de jure and de facto standards.
There's a lot of discussion and talking next to each other about
"the ABI", and which ABI applies to what...
The SVR4 ABI applies to systems claiming compatibility with SVR4, which
was (AFAIK) never a goal for Linux. Before that, there were other ABIs
used by various UNIX systems (BSD, SYSV, ...) and non-Unix systems
(AmigaOS, Atari TOS, MacOS, ...).
From its inception, Linux/m68k used an ABI compatible with SunOS,
which dates back to the MC68000, and was probably the most popular
UNIX OS running on m68k at that time. Several other UNIX vendors
followed a similar path, starting from the MC68000. E.g. the HP-UX Portability Guide[1] states that HP-UX on HP9000/300 (based on SVR2
at that time, apparently) uses an alignment of 2 bytes, too.
SVR4 was an attempt to consolidate the various flavors of UNIX at
that time (with BSD and SYSV being the two largest flavours), and
"rebooted" the ABI. Binary-compatibility with older versions was
ignored, as the UNIX landscape was wildly differing anyway, and
people cared mostly about source-compatibility.
Linux has a strong history of not breaking the ABI between kernel and
user space, so changing that ABI is a no-go. What you do in the layers
above (in the kernel), or above (in userspace) is something different...
[1] http://www.bitsavers.org/pdf/hp/9000_hpux/7.x/98794-90047_HP-UX_Portability_Guide_Sep89.pdf
Unsubstantiated performance claims are no good. I was offering help in substantiating them.
If perf improves, that's validation for the performance argument. If performance impact is insignificant, that's proof against claims of
4-byte alignment decreasing performance.
(Linux kernel has general "no ABI changes, as long as ABI has users"
policy, so verified arguments like above might help sway kernel
maintainers to help with potential 4-byte alignment issues.)
Now, if perf actually decreases with 4-byte alignment setups, it's
something to investigate, and hopefully / eventually to fix. Pinpointing causes for such things is something where I can specifically help.
(Full m68k Debian is too heavy to boot in reasonable time on machines
that Hatari emulates, due to missing crypto acceleration, but IMHO also unnecessary for kernel ABI change discussions.)
On Fri, 2025-06-06 at 20:20 +1000, Finn Thain wrote:
Whereas, the ability to use old binaries is proof that we care about rule #1 don't break userspace.
Who is "we"? The official(!) ABI says that pointers are supposed to be aligned
with 4 bytes, not 2 bytes. It's the current implementation that violates the ABI, not what I want to achieve which is make Linux/m68k adhere to the official
specification.
From its inception, Linux/m68k used an ABI compatible with SunOS,which dates back to the MC68000, and was probably the most popular
You mean Python is broken, as it makes assumptions that are not
guaranteed by the C standard (oops, which one? ;-) ? ;-)
Lots of older packages used to build fine on much more obscure systems
than Linux/m68k. Unfortunately people stopped caring for anything
not 64-bit little endian. Yes, I know saying that doesn't help...
What is your suggested alternative? Do you expect me to patch broken packages
into all eternity? If keeping 2 bytes alignment ABI is so important to so many
people, I would expect proponents to come up with solutions.
So far, I haven't seen any. Just arguments why my approach is wrong.
You are completely ignoring the last sentence I wrote...
So you change the default alignment, bump all so-versions in userspace,
but keep the kernel-userspace ABI the same by adding explicit alignment
tags where needed? Old binaries keep on working, new binaries join
the ecosystem of anything that still builds on 32-bit big-endian ;-)
On Fri, 2025-06-13 at 13:55 +0200, Geert Uytterhoeven wrote:
From its inception, Linux/m68k used an ABI compatible with SunOS,
which dates back to the MC68000, and was probably the most popular
UNIX OS running on m68k at that time. Several other UNIX vendors
followed a similar path, starting from the MC68000. E.g. the HP-UX Portability Guide[1] states that HP-UX on HP9000/300 (based on SVR2
at that time, apparently) uses an alignment of 2 bytes, too.
Linux has a strong history of not breaking the ABI between kernel and
user space, so changing that ABI is a no-go.
Okay and how does this now fix the problems we're having on Linux/m68k?
https://wiki.debian.org/M68k/Alignment
We're compatible to "fails to build from source" now. I'm not sure how this is any helpful.
I'm not sure why several people are contributing to this discussion with
the argument that this change would break the "Linux ABI" when the Linux
ABI is currently broken and doesn't even allow for Python to be built without further modifications.
What is your suggested alternative? Do you expect me to patch broken packages into all eternity? If keeping 2 bytes alignment ABI is so important to so many
people, I would expect proponents to come up with solutions.
So far, I haven't seen any. Just arguments why my approach is wrong.
What you do in the layers
above (in the kernel), or above (in userspace) is something different...
On Fri, 2025-06-13 at 14:09 +0200, Geert Uytterhoeven wrote:
You are completely ignoring the last sentence I wrote...
Because I am *extremely* tired of people heckling this discussion without *helping* me.
I have had multiple moments where I thought to just throw this all into the bin, turn
off the buildds and deleting the m68k archives because it's really hurting my sanity.
I am fully aware that this change breaks the existing ABI. However, as I explained before,
changing the default alignment to 4 bytes is the *only* way to keep this port alive in the
long term and anyone who is interested in this port should either agree with me or present
a suitable alternative to me. The latter still has not happened yet.
What you do in the layers
above (in the kernel), or above (in userspace) is something different...
On Fri, 2025-06-13 at 14:30 +0200, Geert Uytterhoeven wrote:
So you change the default alignment, bump all so-versions in userspace,
but keep the kernel-userspace ABI the same by adding explicit alignment tags where needed? Old binaries keep on working, new binaries join
the ecosystem of anything that still builds on 32-bit big-endian ;-)
I think you're still missing the part that I'm not maintaining my own Linux distribution meaning that I cannot bump SO versions or making any substantial changes to the distributions.
You're not offering help. You, like Finn as well, are trying to block fixing a long-standing problem of Linux/m68k without offering any sustainable alternatives
to fix this problem.
You're not offering help. You, like Finn as well, are trying to block fixing
a long-standing problem of Linux/m68k without offering any sustainable alternatives
to fix this problem.
I didn't see anywhere that Eero was blocking or hinting at blocking. I
only saw Eero offering to collect data, which I think is a good idea.
It might not be directly relevant to the issue at hand, but we shouldn't
say no to more information that might inform these changes, either for better or for worse.
On Fri, 2025-06-13 at 14:30 +0200, Geert Uytterhoeven wrote:
So you change the default alignment, bump all so-versions in userspace,
but keep the kernel-userspace ABI the same by adding explicit alignment
tags where needed? Old binaries keep on working, new binaries join
the ecosystem of anything that still builds on 32-bit big-endian ;-)
I think you're still missing the part that I'm not maintaining my own Linux distribution meaning that I cannot bump SO versions or making any substantial changes to the distributions.>
And I'm not sure why being able to run old binaries on a retro-computing architecture
is is so important for some people that they think it justifies making my life
miserable.
Wouldn't next upgrade completely break user's Debian system so it needs complete re-install?
If true, would separate m68k arch for 4-byte alignment be out of
question, similarly how there have been different ARM arch variants?
PS. I was peripherally involved in the ARM VFP thing, in a Debian
derivative that switched to use VFP before Debian did. So I know a bit
how big thing such transition is, even with the Debian cross-compiling & boot-strapping support being much better now...
On Fri, 2025-06-13 at 17:15 +0300, Eero Tamminen wrote:
Wouldn't next upgrade completely break user's Debian system so it needs
complete re-install?
You would need to extract the glibc package manually from my tests. After that,
upgrading the system should be possible.
If true, would separate m68k arch for 4-byte alignment be out of
question, similarly how there have been different ARM arch variants?
Creating a separate arch would mean patching various parts of Debian which again would involve a lot of work which I don't think is worth the effort.
I don't think the userbase is large enough to warrant all that work.
PS. I was peripherally involved in the ARM VFP thing, in a Debian
derivative that switched to use VFP before Debian did. So I know a bit
how big thing such transition is, even with the Debian cross-compiling &
boot-strapping support being much better now...
That's why I want to make a hard cut and not invest months of work when the userbase consists of just a few people.
Hi Adrian,
On Sat, 7 Jun 2025 at 11:44, John Paul Adrian Glaubitz <[email protected]> wrote:
On Fri, 2025-06-06 at 20:20 +1000, Finn Thain wrote:
Whereas, the ability to use old binaries is proof that we care about rule #1 don't break userspace.
Who is "we"? The official(!) ABI says that pointers are supposed to be aligned
with 4 bytes, not 2 bytes. It's the current implementation that violates the
ABI, not what I want to achieve which is make Linux/m68k adhere to the official
specification.
"The official(!) ABI"...
Official according to what and to who?
There are de jure and de facto standards.
There's a lot of discussion and talking next to each other about
"the ABI", and which ABI applies to what...
The SVR4 ABI applies to systems claiming compatibility with SVR4, which
was (AFAIK) never a goal for Linux. Before that, there were other ABIs
used by various UNIX systems (BSD, SYSV, ...) and non-Unix systems
(AmigaOS, Atari TOS, MacOS, ...).
From its inception, Linux/m68k used an ABI compatible with SunOS,
which dates back to the MC68000, and was probably the most popular
UNIX OS running on m68k at that time. Several other UNIX vendors
followed a similar path, starting from the MC68000. E.g. the HP-UX Portability Guide[1] states that HP-UX on HP9000/300 (based on SVR2
at that time, apparently) uses an alignment of 2 bytes, too.
SVR4 was an attempt to consolidate the various flavors of UNIX at
that time (with BSD and SYSV being the two largest flavours), and
"rebooted" the ABI. Binary-compatibility with older versions was
ignored, as the UNIX landscape was wildly differing anyway, and
people cared mostly about source-compatibility.
Linux has a strong history of not breaking the ABI between kernel and
user space, so changing that ABI is a no-go. What you do in the layers
above (in the kernel), or above (in userspace) is something different...
On Fri, 2025-06-13 at 17:15 +0300, Eero Tamminen wrote:
Wouldn't next upgrade completely break user's Debian system so it needs
complete re-install?
You would need to extract the glibc package manually from my tests. After that,
upgrading the system should be possible.
...If true, would separate m68k arch for 4-byte alignment be out of
question, similarly how there have been different ARM arch variants?
Creating a separate arch would mean patching various parts of Debian which again would involve a lot of work which I don't think is worth the effort.
That's why I want to make a hard cut and not invest months of work when the userbase consists of just a few people.
I really don't understand why anyone can make such a suggestion and
think "Yeah, that's completely reasonable to do. Let's completely change
half of the Debian distribution ..."
Do you expect me to patch broken packages into all eternity?
And I think that the people who keep this running should be able to
decide the future. But that is only my opinion.
A stupid question: is this possible to remove from debian the packets
that are broken?
(I'm sorry if you already answered to this question).
Because I'm afraid that changing the ABI could cause more problems than
it solves.
I think quite a bit more binaries than just Glibc are needed for Debian upgrade tooling to work, but OK.
As to other potential issues...
I assume there are no m68k port packages with closed source executable
code (FW) [1], like the other architectures (esp. x86) have & need, and
that any code intended to work also on non-m68k platform, should be fine with 4-byte alignment.
But what about m68k specific C/C++ and assembly code that may hard-code 2-byte alignment assumptions; is there any tooling to detect (potential) alignment issues in those?
Or is the plan just to rely on packages' self-tests to reveal issues,
and then track them down from there?
[1] Are sources for "bootstra.tos" & "amiboot" anywhere, in case they
need updates:
https://wiki.debian.org/M68k/Installing https://people.debian.org/~wouter/d-i/images/20130502-06:51/tools/atari/ https://people.debian.org/~wouter/d-i/images/20130502-06:51/tools/amiga/
?
Are there any statistics on how many Debian packages do (still) include
m68k assembly?
If that number is limited enough, it could help in getting other people
to review the assembly code for potential alignment issues...
Glibc is likely on top of that list (but also most likely to be
alignment neutral):
glibc$ find -name '*.S' | grep m68k | wc -l
25
As *BSD already uses 4-byte alignment, I assume that for packages
containing m68k assembly that do support / work also on *BSD in addition
to Linux, m68k asm code used on both should work fine, and one needs to review only m68k asm that differs on Linux.
Here's a list of almost 6000 software packages that build fine on m68k with...
4 bytes alignment:
https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/m68k/9.0_2023Q4/All/
Exactly my point. It works on NetBSD, so I'm not worried about Linux.
I don't see in above dir e.g. LLVM or Qt, which were in the Debian 2-byte alignment problems list:
https://wiki.debian.org/M68k/Alignment
Are those in some other place, do they have other problems besides the 2-byte alignment, or am I just blind?
(Many other less relevant packages from that Debian list seem also to be missing from that NetBSD dir.)
I don't see in above dir e.g. LLVM or Qt, which were in the Debian 2-byte alignment problems list:
https://wiki.debian.org/M68k/Alignment
Our package lists include as much as could be built in a given quarter.
The current quarter has, for example, llvm and clang:
https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/m68k/10.0_2025Q1/All/
Are those in some other place, do they have other problems besides the 2-byte
alignment, or am I just blind?
(Many other less relevant packages from that Debian list seem also to be missing from that NetBSD dir.)
There are reports which include build failures that will be available once the quarter is over, but the primary reason packages you might expect to
be there aren't is simply the speed of our build machines.
On Sat, 14 Jun 2025, John Paul Adrian Glaubitz wrote:
Sure, we can remove Python on m68k. But whether it will still be useful after that remains a different question. I would argue we should rather totally drop the port then because Linux without Python doesn't really work these days.
https://lists.debian.org/debian-68k/2024/10/msg00042.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1105110
Honest question, Finn: Why are you even participating in this discussion
when you're neither willing to acknowledge the problem nor willing to
help address it?
Do you think that you just need to bombard me with repeated statements
that I am going to change my mind over something that I have chewed over
for so long?
I think everyone in this thread has now understood that you are neither willing to help resolve these issues nor are you willing to accept my preferred solution that Gentoo and I are already working on.
So, what's the deal with your continued engagement?
On Fri, 2025-06-13 at 17:24 +0200, Laurent Vivier wrote:
A stupid question: is this possible to remove from debian the packets
that are broken?
(I'm sorry if you already answered to this question).
Sure, we can remove Python on m68k. But whether it will still be useful
after that remains a different question. I would argue we should rather totally drop the port then because Linux without Python doesn't really
work these days.
Because I'm afraid that changing the ABI could cause more problems than
it solves.
For what exact reason? NetBSD/m68k runs with 4 bytes alignment.
Why shouldn't this work for Linux?
And I have bootstrapped Debian/m68k using rebootstrap with 4 bytes alignment without any problems. If you think there are problems with 4 bytes alignment, I would like to see them reported.
Sorry, I didn't know you have to coordinate this with the glibc project.
But you have to do something to mark it incompatible with older versions... IIRC, I saw Debian bumping SO versions before...
I think it is generally accepted that this would be a new ABI - a
little similar to MIPS o32 vs n32, but with the twist that all CPUs
support the new ABI and the goal would be for the old ABI to be
entirely replaced.
If that is the case, the real issue would be how to manage the
coexistence with the existing 2 byte alignment ABI port.
One option would be to give it a new port name. Sensible if this was a
more mainstream port, but given the limited Debian engineering
resources (waves at glaubitz@), and desire to replace the existing ABI entirely, I think the effort (and breakage in packages not knowing
about the new cpu name) is probably not warranted.
Given that, I think there are a number of options (of increasing effort):
1) Just to build the new ABI port with the same name, and accept that attempts to run binaries between the two systems will fail without any specific indication
2) Add an ELF note on new ABI binaries (similar to NetBSD/sparc64),
and have the new system fail to run old binaries with a helpful
message
3) Also add a compat layer to the new system to be able to call into a separate set of abi libs and to versioned system calls (rewriting the alignment data as needed), similar to NetBSD with it's a.out (2 byte alignment) to ELF transition (4 byte alignment). That kernel ABI
versioning is likely to be a.... non trivial amount of effort, but
would allow old binaries to run transparently
These stack, so 2) only makes sense if 1) is working, and 3) if 2) is working.
My understanding is glaubitz@ is working on 1). Assuming that goes
well and unlocks a bunch of additional packages for m68k as expected,
then I think it is worth discussing whether 2) or 3) are needed and
who would work on them.
I personally think 2) is definitely worth considering, but as I'm not volunteering to do the work, my opinion can be taken with a pinch of
salt :-p
An elephant in the room is "what if the performance hit of 4 byte
alignment is significant".
In that case some people may want to continue the 2 byte alignment
port (though I think it's safe to say at this point that unless it
reduces the performance to NS32008 leves, glaubitz@ plans to complete
and maintain the 4 byte alignment port).
In that case adding 2) plus the code to detect and reject new ABI
binaries on old systems becomes if anything more interesting, and....
I'm sure we can look forward to more animated discussions on these
lists...
You will create the exact same problem you want to fix: we can guessCould you point me to these packages which assume 2 bytes alignment? I'm genuinely
some softwares are built on linux/m68k with 2byte alignment in mind. So
once the ABI is changed, you'll have to track them to fix them.
interested as I would like to put these up on the wiki. So far I haven't found any.
I have used Debian's rebootstrap to create an initial set of m68k packages with
4 bytes alignment and didn't run into any problems yet.
The Gentoo developers have also successfully created a chroot with 4 bytes alignment:
https://dev.gentoo.org/~dilfridge/m68k/
I have tried it and it worked fine for me with qemu-user.
So, if there is any software that is incompatible with 4 bytes alignment on m68k, I
would like to hear about it.
Le 14/06/2025 à 09:21, John Paul Adrian Glaubitz a écrit :
On Fri, 2025-06-13 at 17:24 +0200, Laurent Vivier wrote:
A stupid question: is this possible to remove from debian the packets that are broken?
(I'm sorry if you already answered to this question).
Sure, we can remove Python on m68k. But whether it will still be useful after that remains a different question. I would argue we should rather totally drop the port then because Linux without Python doesn't really
work these days.
You can see the fix for python has been merged 5 days ago...
Because I'm afraid that changing the ABI could cause more problems than it solves.
For what exact reason? NetBSD/m68k runs with 4 bytes alignment.
Why shouldn't this work for Linux?
The problem is not the 4 byte alignment but changing the ABI.
You will create the exact same problem you want to fix: we can guess
some softwares are built on linux/m68k with 2byte alignment in mind. So
once the ABI is changed, you'll have to track them to fix them.
And I have bootstrapped Debian/m68k using rebootstrap with 4 bytes alignment
without any problems. If you think there are problems with 4 bytes alignment,
I would like to see them reported.
Adrian, I respect all the work you do for debian ports and particularly
on m68k, but I want to point out that this ABI change can generate more problems than it solves.
Honest question, Finn: Why are you even participating in this discussion when you're neither willing to acknowledge the problem nor willing to
help address it?
You and I don't discuss much; you ignore most of what I've said, then tell me that what I said is off-topic. LOL.
Do you think that you just need to bombard me with repeated statements that I am going to change my mind over something that I have chewed over for so long?
You're quite right, I need to stop responding to repeated nonsense -- I
will quit it.
I think everyone in this thread has now understood that you are neither willing to help resolve these issues nor are you willing to accept my preferred solution that Gentoo and I are already working on.
I've no idea who "everyone" is... but I'm speaking both to those participating in this thread and to those who know better.
As for "unwilling to help", I help where I see a need.
As for solutions, well, you have one, but you'd create more problems than you'd solve.
So, what's the deal with your continued engagement?
I'm not here to stop you exercising whatever power you've garnered over whatever domain you've claimed. (No wonder you're baffled by my presence.)
I'm here to bell the cat. What you're doing is harmful. Forking the
packages that make up your distribution is harmful and so is fragmenting
the ABI.
You can't improve Debian by refusing to acknowledge it's limitations.
You can't improve the Debian experience by railroading users.
You can't improve upstream codebases by papering over their mistakes.
You can't improve collaboration by ignoring the advice of upstream toolchain and
kernel developers.
You can't have a stable ABI without consensus.
You can't improve the long term prospects for the Linux/m68k project until you
understood how it got to where it was when you arrived.
So to answer your fine question, Adrian, I continue to engage out of hope that you will finally realize that there are better ways to serve the community than the path you're on.
[1] https://github.com/python/cpython/pull/135209
On Mon, 2025-06-16 at 10:00 +0200, Laurent Vivier wrote:
Could you point me to these packages which assume 2 bytes alignment? I'm genuinely
interested as I would like to put these up on the wiki. So far I haven't found any.
I have used Debian's rebootstrap to create an initial set of m68k packages with
4 bytes alignment and didn't run into any problems yet.
The Gentoo developers have also successfully created a chroot with 4 bytes alignment:
https://dev.gentoo.org/~dilfridge/m68k/
I have tried it and it worked fine for me with qemu-user.
So, if there is any software that is incompatible with 4 bytes alignment on m68k, I
would like to hear about it.
qemu-user is one of these softwares that know m68k has alignment of
2byte. All the structures translated from the m68k chroot to the host
kernel are with a 2byte alignment.
And yet it works without any problems so far. Please try the Gentoo chroot yourself.
Could you point me to these packages which assume 2 bytes alignment? I'm genuinely
interested as I would like to put these up on the wiki. So far I haven't found any.
I have used Debian's rebootstrap to create an initial set of m68k packages with
4 bytes alignment and didn't run into any problems yet.
The Gentoo developers have also successfully created a chroot with 4 bytes alignment:
https://dev.gentoo.org/~dilfridge/m68k/
I have tried it and it worked fine for me with qemu-user.
So, if there is any software that is incompatible with 4 bytes alignment on m68k, I
would like to hear about it.
qemu-user is one of these softwares that know m68k has alignment of
2byte. All the structures translated from the m68k chroot to the host
kernel are with a 2byte alignment.
Because most of the structures are correctly aligned by default, but
some of them not. You must run glibc test suite and LTP to be sure there
is no regression.
In QEMU, alignment is defined here:
include/user/abitypes.h
for m68k the values to change are:
#ifdef TARGET_M68K
#define ABI_INT_ALIGNMENT 2
#define ABI_LONG_ALIGNMENT 2
#define ABI_LLONG_ALIGNMENT 2
#endif
And there will be a problem with binfmt_misc because we can't rely on
the ELF signature to know which qemu-user to run, the one with 2byte alignment or the one with 4byte alignment?
[1] https://www.netbsd.org/docs/kernel/elf-notes.html
The Linux kernel also knows m68k has an alignment of 2 bytes.
And yet it works without any problems so far. Please try the Gentoo chroot yourself.
Because most of the structures are correctly aligned by default, but
some of them not. You must run glibc test suite and LTP to be sure there
is no regression.
Indeed.
In QEMU, alignment is defined here:
include/user/abitypes.h
for m68k the values to change are:
#ifdef TARGET_M68K
#define ABI_INT_ALIGNMENT 2
#define ABI_LONG_ALIGNMENT 2
#define ABI_LLONG_ALIGNMENT 2
#endif
Note that it also used to have:
#ifdef TARGET_CRIS
#define ABI_SHORT_ALIGNMENT 1
#define ABI_INT_ALIGNMENT 1
#define ABI_LONG_ALIGNMENT 1
#define ABI_LLONG_ALIGNMENT 1
#endif
and still has:
#if (defined(TARGET_I386) && !defined(TARGET_X86_64)) \
|| defined(TARGET_SH4) \
|| defined(TARGET_OPENRISC) \
|| defined(TARGET_MICROBLAZE) \
|| defined(TARGET_NIOS2)
#define ABI_LLONG_ALIGNMENT 4
#endif
which will probably become the next victim of the 64-bit little-endian natural-alignment monoculture...
And there will be a problem with binfmt_misc because we can't rely on
the ELF signature to know which qemu-user to run, the one with 2byte alignment or the one with 4byte alignment?
Exactly.
[1] https://github.com/search?q=repo%3Aqemu%2Fqemu%20PT_NOTE&type=code
And there will be a problem with binfmt_misc because we can't rely onWhat about the ELF note [1] that David Brownlee suggested? Can these be used?
the ELF signature to know which qemu-user to run, the one with 2byte
alignment or the one with 4byte alignment?
Adrian
[1]https://www.netbsd.org/docs/kernel/elf-notes.html
Le 16/06/2025 à 11:00, John Paul Adrian Glaubitz a écrit :
And there will be a problem with binfmt_misc because we can't rely onWhat about the ELF note [1] that David Brownlee suggested? Can these be used?
the ELF signature to know which qemu-user to run, the one with 2byte alignment or the one with 4byte alignment?
Adrian
[1]https://www.netbsd.org/docs/kernel/elf-notes.html
binfmt_misc doesn't use the sections to select the interpreter, but the
128 first bytes of the file.
I think you need to change the ABI type in the ELF header: https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
On Mon, 2025-06-16 at 11:10 +0200, Laurent Vivier wrote:
Le 16/06/2025 à 11:00, John Paul Adrian Glaubitz a écrit :
And there will be a problem with binfmt_misc because we can't rely onWhat about the ELF note [1] that David Brownlee suggested? Can these be used?
the ELF signature to know which qemu-user to run, the one with 2byte
alignment or the one with 4byte alignment?
Adrian
[1]https://www.netbsd.org/docs/kernel/elf-notes.html
binfmt_misc doesn't use the sections to select the interpreter, but the
128 first bytes of the file.
I think you need to change the ABI type in the ELF header:
https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
How does binfmt_misc handle the various MIPS ABIs then?
binfmt_misc doesn't use the sections to select the interpreter, but the 128 first bytes of the file.
I think you need to change the ABI type in the ELF header: https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
How does binfmt_misc handle the various MIPS ABIs then?
It doesn't and it's a problem.
On Mon, 2025-06-16 at 11:26 +0200, Laurent Vivier wrote:
binfmt_misc doesn't use the sections to select the interpreter, but the >>>> 128 first bytes of the file.
I think you need to change the ABI type in the ELF header:
https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
How does binfmt_misc handle the various MIPS ABIs then?
It doesn't and it's a problem.
Very interesting. Is there a bug report for that?
Hi Laurent,
On Mon, 16 Jun 2025 at 11:16, Laurent Vivier <[email protected]> wrote:
Le 16/06/2025 à 11:00, John Paul Adrian Glaubitz a écrit :
And there will be a problem with binfmt_misc because we can't rely onWhat about the ELF note [1] that David Brownlee suggested? Can these be used?
the ELF signature to know which qemu-user to run, the one with 2byte
alignment or the one with 4byte alignment?
Adrian
[1]https://www.netbsd.org/docs/kernel/elf-notes.html
binfmt_misc doesn't use the sections to select the interpreter, but the
128 first bytes of the file.
I think you need to change the ABI type in the ELF header:
https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
Interesting....
Does any system actually use ABI (byte 7) = 3 (Linux)?
All of amd64/arm/arm64/ia64/i386/m68k/microblaze/mips(el)/powerpc/risvc/s390/sh/sparc
seem to use 0 (SYSV).
#define ELFOSABI_NONE 0
#define ELFOSABI_LINUX 3
Ah, parisc does. And C6x uses 0x40.
On Mon, 2025-06-16 at 12:07 +0200, Geert Uytterhoeven wrote:
I think you need to change the ABI type in the ELF header:
https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
Interesting....
Does any system actually use ABI (byte 7) = 3 (Linux)?
All of amd64/arm/arm64/ia64/i386/m68k/microblaze/mips(el)/powerpc/risvc/s390/sh/sparc
seem to use 0 (SYSV).
#define ELFOSABI_NONE 0
#define ELFOSABI_LINUX 3
Strictly speaking, a value of 0x00 indicates SysV ABI [1].
But maybe we could use 0x03 for Linux/m68k with 4 bytes alignment.
Adrian
[1] https://en.wikipedia.org/wiki/Executable_and_Linkable_Format#ELF_header
I think you need to change the ABI type in the ELF header: https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
Interesting....
Does any system actually use ABI (byte 7) = 3 (Linux)?
All of amd64/arm/arm64/ia64/i386/m68k/microblaze/mips(el)/powerpc/risvc/s390/sh/sparc
seem to use 0 (SYSV).
#define ELFOSABI_NONE 0
#define ELFOSABI_LINUX 3
[1] https://en.wikipedia.org/wiki/Executable_and_Linkable_Format#ELF_header
On Mon, 2025-06-16 at 13:05 +0200, Laurent Vivier wrote:
I think an e_flags with a new value like EF_M68K_ABI2 would be more appropriate.
How is it currently used on m68k and does QEMU use it? I think that would be certainly a way to go.
On Mon, 2025-06-16 at 13:05 +0200, Laurent Vivier wrote:
I think an e_flags with a new value like EF_M68K_ABI2 would be more appropriate.
How is it currently used on m68k and does QEMU use it? I think that would be certainly a way to go.
I wrote that message on Friday. Odd that your email client claims it was sent today.
Besides that, I would like to point again at what John Klos wrote in reply to Finn [1].
On Mon, 16 Jun 2025 at 13:48, John Paul Adrian Glaubitz <[email protected]> wrote:
On Thu, 2025-06-12 at 08:25 +0000, Administrator @ R·V·E wrote:
Thanks for your great hard work and efforts to mantain the various and now
considered exotic architectures running Debian, Adrian!
Thanks, and you're welcome. Unfortunately, some people like Finn and Eero don't
appreciate these efforts and seem to think that this all comes at zero costs.
Please calm down...
[1] https://lists.debian.org/debian-68k/2025/05/msg00051.html
On Jun 16, 2025, at 2:10 AM, Laurent Vivier <[email protected]> wrote:
I think you need to change the ABI type in the ELF header: https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
On Jun 16, 2025, at 2:10 AM, Laurent Vivier <[email protected]> wrote:
I think you need to change the ABI type in the ELF header: https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
4-byte alignment binaries should have ELFOSABI_SYSV (0) (since that ABI spec is where the 4 byte alignment comes from). If Linux/m68k is already using that,
then those binaries are broken by definition.
Let’s hope existing Linux/m68k binaries are using ELFOSABI_LINUX / ELFOSABI_GNU (3)
(sorry, I don’t have any handy to check).
If the existing binaries correctly label themselves has having the Linux-specific ABI,
then this is trivial and there’s no reason to use a note to differentiate them.
On Jun 16, 2025, at 2:10 AM, Laurent Vivier <[email protected]> wrote:
I think you need to change the ABI type in the ELF header: https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
4-byte alignment binaries should have ELFOSABI_SYSV (0) (since that ABI
spec is where the 4 byte alignment comes from). If Linux/m68k is
already using that, then those binaries are broken by definition.
Let’s hope existing Linux/m68k binaries are using ELFOSABI_LINUX / ELFOSABI_GNU (3) (sorry, I don’t have any handy to check).
If the existing binaries correctly label themselves has having the Linux-specific ABI, then this is trivial and there’s no reason to use a note to differentiate them.
How is messing with a hobbyist project "harmful" in any way? That makes
no sense.
If your port was a pure hobbyist project, you would never have brought
your complaint to the upstream mailing lists, where developers have to
work with ALL interested parties and make the necessary compromises.
But, as usual, you're trying to have it both ways. You pretend that wiping wiping your slate clean and starting over doesn't impact anyone else. But then you complain when the upstream projects don't care to invest effort into your scheme.
The way to find a compromise is to build the thing you need, and then, if any of it is found to be useful upstream, send patches! That's how this process has always worked, has it not?
Moreover, to the extent that those patches get merged, we will have the beginnings of a second ABI with a second tuple. To the extend that those patches get rejected, you will have a fork on your hands.
So, some upstream developers will have to support both ABIs (for them, you've just created work). Other developers will have to choose between either one (for them, you've just make collaboration more difficult).
This is a lose/lose proposition. And if you think I'm wrong about that, please just send patches and demonstrate why.
I only know about Gentoo and Debian and both want to make the switch.
Buildroot? Which is probably where the real product users (using Coldfire) are hiding...
Coldfire already uses a different alignment (for the stack):
/* ColdFire and fido strongly prefer a 32-bit aligned stack. */
#define PREFERRED_STACK_BOUNDARY \
((TARGET_COLDFIRE || TARGET_FIDOA) ? 32 : 16)
It's instruction set is also not fully compatible AFAIK.
Sure, but you will impact it regardless.
Hello Geert,
On Wed, 2025-06-18 at 11:56 +0200, Geert Uytterhoeven wrote:
Coldfire already uses a different alignment (for the stack):
/* ColdFire and fido strongly prefer a 32-bit aligned stack. */
#define PREFERRED_STACK_BOUNDARY \
((TARGET_COLDFIRE || TARGET_FIDOA) ? 32 : 16)
It's instruction set is also not fully compatible AFAIK.
Sure, but you will impact it regardless.
Could you please elaborate this a bit more, please?
Coldfire is handled as a separate target via TARGET_COLDFIRE in GCC, so we would certainly be able to toggle the alignment settings independent of what's done on classic m68k.
In the Linux kernel, Coldfire is also a separate
arch, so the alignment settings can also be handled there separately if necessary.
It's not really necessary to enforce this on Coldfire. However, since buildroot
builds completely from source, it wouldn't even be a problem to change the alignment
there as well.
PS: I would like to lead a discussion on how to implement this properly and not continue to have one why this shouldn't be done as the latter is continuing
to take a lot of energy.
Adrian
Could you please elaborate this a bit more, please?
Coldfire is handled as a separate target via TARGET_COLDFIRE in GCC, so we would certainly be able to toggle the alignment settings independent of what's done on classic m68k.
The net out is that it is the same gcc compiler, m68k-linux-gcc.
ColdFire just needs specific code generation via command line switches,
like -m5200 (or -m5206e or -m5307 or -mcfv4e, etc). This is the same way
you would specify 680x0 level - m68020, -m68030, etc.
The bulk of the instruction set is the same. Asm code will look totally familiar to anyone who knows m68k :-) One notable difference is that
there is a more limited set addressing modes for some instructions.
FWIW ColdFire currently uses the same ABI as all other m68k, so it uses 2-byte alignment today.
In the Linux kernel, Coldfire is also a separate
arch, so the alignment settings can also be handled there separately if necessary.
ColdFire is not handled as a separate architecture in linux, it is just a variant of m68k - so uses arch/m68k in the source.
It's not really necessary to enforce this on Coldfire. However, since buildroot
builds completely from source, it wouldn't even be a problem to change the alignment
there as well.
Yes, that is totally right in my experience. Certainly in my ColdFire work
it is pretty much always a build-everything approach via buildroot or similar.
I wouldn't think an ABI change would actually worry too many ColdFire uses, they don't use distributions like debian on them. (I would love to hear from anyone who does!).
True, but you won't be able to run any classic m68k binaries on ColdFire and the other way around, are you?
IIIRC if you use a proper subset of the user mode instructions, you
can create binaries that run on both.
Hi Adrian,
On Wed, 18 Jun 2025 at 14:27, John Paul Adrian Glaubitz <[email protected]> wrote:
On Wed, 2025-06-18 at 22:21 +1000, Greg Ungerer wrote:
Could you please elaborate this a bit more, please?
Coldfire is handled as a separate target via TARGET_COLDFIRE in GCC, so we >>>> would certainly be able to toggle the alignment settings independent of >>>> what's done on classic m68k.
The net out is that it is the same gcc compiler, m68k-linux-gcc.
ColdFire just needs specific code generation via command line switches,
like -m5200 (or -m5206e or -m5307 or -mcfv4e, etc). This is the same way >>> you would specify 680x0 level - m68020, -m68030, etc.
Yes, but there is a TARGET_COLDFIRE macro as I mentioned above which could >> be used to trigger which alignment to use by default. I don't see how that >> would complicate things.
The bulk of the instruction set is the same. Asm code will look totally
familiar to anyone who knows m68k :-) One notable difference is that
there is a more limited set addressing modes for some instructions.
True, but you won't be able to run any classic m68k binaries on ColdFire
and the other way around, are you?
IIIRC if you use a proper subset of the user mode instructions, you
can create binaries that run on both.
It's not really necessary to enforce this on Coldfire. However, since buildroot builds completely from source, it wouldn't even be a problem
to change the alignment there as well.
Yes, that is totally right in my experience. Certainly in my ColdFire
work it is pretty much always a build-everything approach via buildroot
or similar. I wouldn't think an ABI change would actually worry too many ColdFire uses, they don't use distributions like debian on them. (I
would love to hear from anyone who does!).
On Wed, 2025-06-18 at 13:19 +1000, Finn Thain wrote:
Do you know of a good solution for this open bug? https://sourceware.org/bugzilla/show_bug.cgi?id=30273
The proper solution would be to actually adhere to the official SVR4 ABI
when declaring elfosabi == GDB_OSABI_SVR4 and using GDB_OSABI_LINUX for
the old Linux ABI.
This bug is another example why it was not a good idea to ignore the
official AT&T System V ABI ELF specification as it proves that
independent upstream projects look at the actual official specification
when implementing code.
On Wed, 18 Jun 2025, Greg Ungerer wrote:
It's not really necessary to enforce this on Coldfire. However, since
buildroot builds completely from source, it wouldn't even be a problem
to change the alignment there as well.
Yes, that is totally right in my experience. Certainly in my ColdFire
work it is pretty much always a build-everything approach via buildroot
or similar. I wouldn't think an ABI change would actually worry too many
ColdFire uses, they don't use distributions like debian on them. (I
would love to hear from anyone who does!).
That may work for end-users with a vendor BSP. But upstream developers
need to be able to swap components. In general, when debugging I often
have to run old binaries to find out whether I'm dealing with a deeper regression or not. Also, there is the bisection problem. It's not just a couple of distros who get to pay for an ABI break. It's the entire
ecosystem.
On 19/6/25 08:29, Finn Thain wrote:
On Wed, 18 Jun 2025, Greg Ungerer wrote:
It's not really necessary to enforce this on Coldfire. However,
since buildroot builds completely from source, it wouldn't even be a
problem to change the alignment there as well.
Yes, that is totally right in my experience. Certainly in my ColdFire
work it is pretty much always a build-everything approach via
buildroot or similar. I wouldn't think an ABI change would actually
worry too many ColdFire uses, they don't use distributions like
debian on them. (I would love to hear from anyone who does!).
That may work for end-users with a vendor BSP. But upstream developers
need to be able to swap components. In general, when debugging I often
have to run old binaries to find out whether I'm dealing with a deeper regression or not. Also, there is the bisection problem. It's not just
a couple of distros who get to pay for an ABI break. It's the entire ecosystem.
I am sure there is value in that for some. Like I said though that has
not been my experience with ColdFire. And by that I mean as the upstream maintainer of ColdFire Linux support for +20 years. I pretty mush
_always_ build kernel + libs + user for testing even small kernel
changes.
My standard small system build takes less than 1 minute for everything. Again, I am just relating my experience with this - admittedly probably
not typical of actual end users.
FWIW even when I was working on shipping ColdFire based products my
firmware was always a complete update, no separate kernel and user space updates. Typical of small embedded systems. I can't actually remember
many times I have run with a previously compiled user space.
On Thu, 19 Jun 2025, Greg Ungerer wrote:
On 19/6/25 08:29, Finn Thain wrote:
On Wed, 18 Jun 2025, Greg Ungerer wrote:
It's not really necessary to enforce this on Coldfire. However,
since buildroot builds completely from source, it wouldn't even be a >>>>> problem to change the alignment there as well.
Yes, that is totally right in my experience. Certainly in my ColdFire
work it is pretty much always a build-everything approach via
buildroot or similar. I wouldn't think an ABI change would actually
worry too many ColdFire uses, they don't use distributions like
debian on them. (I would love to hear from anyone who does!).
That may work for end-users with a vendor BSP. But upstream developers
need to be able to swap components. In general, when debugging I often
have to run old binaries to find out whether I'm dealing with a deeper
regression or not. Also, there is the bisection problem. It's not just
a couple of distros who get to pay for an ABI break. It's the entire
ecosystem.
I am sure there is value in that for some. Like I said though that has
not been my experience with ColdFire. And by that I mean as the upstream
maintainer of ColdFire Linux support for +20 years. I pretty mush
_always_ build kernel + libs + user for testing even small kernel
changes.
OK, so you're not building binutils, newlib, gcc, gdb etc. with each revision. Do you use a board support package (BSP) from the vendor?
My standard small system build takes less than 1 minute for everything.
Again, I am just relating my experience with this - admittedly probably
not typical of actual end users.
FWIW even when I was working on shipping ColdFire based products my
firmware was always a complete update, no separate kernel and user space
updates. Typical of small embedded systems. I can't actually remember
many times I have run with a previously compiled user space.
Given that on-chip RAM is scarce on Coldfire devices, it seems entirely plausible that an alignment change could result in ENOMEM after a rebuild
-- unless the toolchain offered a choice of ABI.
So this becomes a burden for those who maintain tooling that deals with
ABIs, as well as for the vendor which has to support its BSP -- unless the vendor also happens to desire a choice of alignment (that's why I raised
that question on 6/6).
On Jun 18, 2025, at 10:56 PM, Greg Ungerer <[email protected]> wrote:
Granted many ColdFire platforms are short on RAM. Size is a problem.
New versions of packages almost always get larger, that is an on-going problem. Heck even version to version kernel bloat is a problem.
Especially as the years go on.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 43:08:07 |
| Calls: | 12,111 |
| Calls today: | 2 |
| Files: | 15,008 |
| Messages: | 6,518,438 |