the m68k port has reached the point where switching the default
alignment from 16-bit to 32-bit is inevitable as the number of packages affected by alignment issues have become too large. It even includes
Python 3.13 these days.
On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote:
the m68k port has reached the point where switching the default
alignment from 16-bit to 32-bit is inevitable as the number of packages affected by alignment issues have become too large. It even includes Python 3.13 these days.
Are there any bug reports you could link to, in support of the "too large" claim?
Hello,
the m68k port has reached the point where switching the default alignment from 16-bit to 32-bit is inevitable as the number of packages affected by alignment issues have become too large. It even includes Python 3.13 these days.
Since I don't think the situation is getting better by postponing action here in the future, I suggest that we have a virtual meetup soonish to discuss a strategy for switching the port over.
Maybe a page could be created either on the Debian or Gentoo Wiki to
draft a design
for switching over. Geert also mentioned that we should use this
transition to clean
up the kernel ABI by removing old syscalls and switch the kernel to asm-generic which
is why I have included Arnd Bergmann in the CC list.
Please join #gentoo-m68k on Libera if you want to discuss this issue.
On Fri, 2024-10-25 at 09:55 +0000, Arnd Bergmann wrote:
I think the idea of using the generic syscall ABI (in particular
the time64-only variant) makes sense if there is going to be a
new ABI, and I can help figure out what needs to be done in the
kernel for that.
I don't actually know whether this would be a completely new ABI
as m68k has supported 32-bit alignment through the "-malign-int"
switch for a long time.
The question is really if it's already too late to do it now,
given the scope of the project and the limited developer
resources. Maintaining two ABIs in the kernel and toolchain
longterm is likely going to make things harder, and phasing
out the existing ABI completely will likely take more than
a decade. I expect that this is the same timeframe (mid-2030s)
by which we will be debating the removal of any 32-bit
targets from the kernel, in particular if we also want to
add 128-bit targets.
I was not talking about maintaining two separate ABIs and I don't
think it makes much sense to keep the old ABI around.
Based on those experiences, I think there is a significant
chance that adding a new ABI is going to make things harder
to maintain for both distro and kernel maintainers rather
than easier, regardless of how much better the new ABI is.
The m68k port is already half broken because of the 16-bit
alignment and I have to admit I starting to get tired of
people telling me that switching the default alignment is a
bad idea.
A current example is Python 3.13 which just crashes with the
default alignment but builds just fine with "-malign-int".
I really don't understand why there is such a big resistance of
switching a port over to a different alignment which allegedly
no one is using or maintaining.
Someone made a bad design decision 40 years ago and we're not
allowed to fix that because someone might run an old binary
from the 80ies on a current version of the Linux kernel.
Doing it without a migration path seems worse to me,
as this would mean breaking every single existing
installation between two kernels, and making it impossible
to bisect other issues, and breaking the rule #1.
as m68k has supported 32-bit alignment through the "-malign-int"
switch for a long time.
Question is, do we need a kernel change for this at all?
Is there anything in the kernel/userland interface that
gets affected by this, or do these APIs use sufficient
explicit padding? Has anyone looked at this?
Already basic things like struct stat64 will break.
On Fri, 2024-10-25 at 20:06 +1100, Finn Thain wrote:
On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote:
the m68k port has reached the point where switching the default
alignment from 16-bit to 32-bit is inevitable as the number of
packages affected by alignment issues have become too large. It even includes Python 3.13 these days.
Are there any bug reports you could link to, in support of the "too
large" claim?
The following packages require 32-bit alignment:
- mold
- LLVM
- gccgo
- Qt5 (several packages affected)
- Qt6 (several packages affected)
- OpenJDK (all versions)
- Python >= 3.13
- Rust
Those are the most important projects from the tip of my head, but they
are already the biggest blockers. There is no chance that the upstream maintainers will adjust their packages for 16-bit alignment, so these
will be forever broken on m68k if we don't switch.
I understand that this might be a painful transition, but I don't see
any other way to keep the m68k port alive in the foreseeable future
unless we fix this problem which keeps blocking the port.
You can see how the Debian m68k port has been falling behind because of
the alignment issues in these statistics: https://buildd.debian.org/stats/graph-ports-big.png
Additionally… has anyone done the simple “enable -malign-int
in GCC, begin rebuilding stuff, first glibc, then others,
see what breaks”? Is there sufficient effect that we cannot
incrementally change over?
The following packages require 32-bit alignment:
- mold
- LLVM
- gccgo
- Qt5 (several packages affected)
- Qt6 (several packages affected)
- OpenJDK (all versions)
- Python >= 3.13
- Rust
That seems to imply that someone requires that those packages are ported.
Absent the right conditions, perhaps it is best focus limited porter and >developer effort on patching only those packages that are really required.
That seems to imply that someone requires that those packages are
ported.
Yes, we do. Rust especially is killing the entire FOSS ecosystem.
These all are conditio sine qua nōn when it comes to continuing
Linux/m68k, as a whole.
Absent the right conditions, perhaps it is best focus limited porter and >developer effort on patching only those packages that are really required.
I tried my hand at Qt5. About 20 man-hours in I essentially gave up,
and that was without even getting to something I could put to a
compile and runtime test.
“Natural” alignment of data types has essentially become a requirement these days, and m68k is the only true outlyer (i386 could in theory, but
the Unix psABI designers were sensible enough to not do it).
That seems to imply that someone requires that those packages are
ported.
Yes, we do. Rust especially is killing the entire FOSS ecosystem.
These all are conditio sine qua nōn when it comes to continuing
Linux/m68k, as a whole.
I think that's overstating the case. Alternatives to rust are available
and will be for the foreseeable future. Most notably,
https://gcc.gnu.org/wiki/RustFrontEnd
I expect alignment assumptions like that will end up putting more
platforms in the same predicament in future.
"Natural" alignment is meaningless in the context of portable data >structures, as they exist without reference to any particular integer
Q. What is the size of this struct, assuming baa.b is naturally aligned?
struct baa {
int a;
long long b;
};
https://gcc.gnu.org/wiki/RustFrontEnd
That’s assuming it can build the same stuff the same way so it can be
used in packaging.
I expect alignment assumptions like that will end up putting more >platforms in the same predicament in future.
No, all the other platforms use natural alignment.
"Natural" alignment is meaningless in the context of portable data >structures, as they exist without reference to any particular integer
Yeah, but in practice, all we have is ILP32 and LP64;
the Windows® world has LLP64 in addition. And natural alignment just
means that all the data types’ alignment is their size. (Which kind of makes sense, so you can read them without getting an unalignment trap on SPARC or so.)
Q. What is the size of this struct, assuming baa.b is naturally aligned?
struct baa {
int a;
long long b;
};
For ILP32, LP64 and LLP64, it’s 4 (a) + 4 (padding) + 8 (b) = 16 chars.
More importantly, and relevant for Qt, struct baa is also 8-byte
aligned...
That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
case on my Linux/i686 system. 4 != 8:
struct baa {
int a;
long long b;
} foo;
More importantly, and relevant for Qt, struct baa is also 8-byte
aligned...
If the struct itself is not naturally aligned, it too will eventually
break someone's assumption of natural alignment.
Finn Thain dixit:
That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
case on my Linux/i686 system. 4 != 8:
struct baa {
int a;
long long b;
} foo;
That struct is just 12 bytes for you then?
That’s possible on i386 but almost nowhere else, and has multiple
penalties on i386 even (cacheline split, loss of atomicity, merging
of accesses, possible cross-page split, …).
Of course, in this case, the software author ought to have made the
padding explicit or, better, sorted the struct members. But if all did
that we wouldn’t have this problem.
More importantly, and relevant for Qt, struct baa is also 8-byte
aligned...
If the struct itself is not naturally aligned, it too will eventually >break someone's assumption of natural alignment.
No, structs are not naturally aligned but aligned to the max() of the alignment of its members. Natural alignment is only applied to primitive types.
On Sat, 26 Oct 2024, Andreas Schwab wrote:
Already basic things like struct stat64 will break.
OK. Then, flag day, I guess.
How do we model this in Debian. Rename libc to libc6.1 and
conflict with libc6 to force no coïnstallability, rename the
architecture from m68k to… something else, or…?
But then, this does give the kernel side a chance to clean
it up, even to model it like a completely new ILP32 port with
no historical things to account for. And no kernel then needs
to support both at the same time. (Or the new syscall ABI
could use something different than trap #0, if that is even
possible.)
How do we model this on the ELF side? (How do ARM and MIPS
distinguish between their different same-bitness ABIs there?)
Or do we just keep everything and old programs will just fail
on their first syscall? (Another point in favour of not using
the same trap.) Less toolchain changes. This also impacts how
distros can handle this. From what mgorny writes Gentoo also
doesn’t like rebootstrap-everything flag days with no simple
upgradability, but it looks like this can’t be avoided with
justifiable effort… unless the new ABI uses a different trap,
the kernel supports both at the same time, and ELF mechanisms
*and* paths (e.g. Multi-Arch) are used to distinguish them,
so they can coëxist in the same system. (Although different
M-A path would (I think) mean different Debian architecture,
so it’d not be a clean upgrade either; crossgrades do work in
theory these days, but only if the package versions are
exactly identical, so this is very much not going to happen
for m68k.)
So I think we need a rebootstrap with requiring users to
reinstall (and then need no coexistence within the same
running system).
Can we cheat and just not change the dpkg arch, GNU triplet,
ELF headers etc. and just make sure that old syscalls won’t
continue to work? (Or, some could even continue to work.)
The danger of this is that if someone has an old .a lying
around and links to it, they can get misbehaviour *if* it
is affected by the ABI change.
Otherwise, I think we at least need something ELFy that
binutils will refuse to link with older ELFs and go from
there.
Looking at binutils… ARM has special code like:
/* Cannot mix APCS26 and APCS32 code. */
if ((in_flags & EF_ARM_APCS_26) != (out_flags & EF_ARM_APCS_26))
return FALSE;
/* Cannot mix float APCS and non-float APCS code. */
if ((in_flags & EF_ARM_APCS_FLOAT) != (out_flags & EF_ARM_APCS_FLOAT))
return FALSE;
But m68k doesn’t, so old binutils would link against new
objects if we just add something like EF_* there. Again,
the question is how much we can “cheat” for a low-user-
count arch vs. how correct we want to do this. I’m not
sure allocating a new EM_* distinct from EM_68K would be
globally welcomed. (On that note, there’s EM_COLDFIRE, but
Linux/coldfire never took off, did it?) No EI_OSABI use,
either. So, besides new EM_*, I can’t think of a way that
old binutils won’t mix objects (and old kernels won’t try
to execute new binaries), unless making things fail at the
first syscall is an option, but getting one will mean more
delays and more to change.
So many ways…
bye,
//mirabilos
On Sun, Oct 27, 2024, at 06:16, Finn Thain wrote:
Right. And I don't think the problem is going to go away. One solution
that is sometimes raised is better tooling. I'm not sure how that would
That struct is just 12 bytes for you then?
Right. i686 and m68k agree on that.
The other ones that have misaligned 'long long' variables are
arc
arm (OABI only)
csky
microblaze
nios2
openrisc
superh
i386
The 32-bit architectures that use a natural 8-byte
alignment are
arm (EABI)
parisc
mips
powerpc
riscv
s390
sparc
xtensa
I think it makes sense to go through these anyway and annotate
them to document and enforce the alignment we actually want
padding. If all of them get fixed alignment, this would allow
switching -malign-int on independently for userspace and
kernel without changing the ABI. Any duplicated copies of
the struct definitions in userspace of course would need
the same changes.
There is plenty of Linux on ColdFire, but all the m68k'isms apply the same.
+1Why don't you use JavaScript? I also don't like enabling JavaScript inBecause I use lynx as browser.
On Sun, 27 Oct 2024, Arnd Bergmann wrote:
I think it makes sense to go through these anyway and annotate
them to document and enforce the alignment we actually want
That would be good in general, yes. I’d personally argue for
using explicit padding members (please do NOT use __unused,
rather __pad1 __pad2 etc. or __unused1, etc. as __unused is
used (hah) by BSD code for the GCC attribute a lot) and in
cases where nōn-natural alignment is needed, GCC __packed__
plus explicit padding. That is easier to read than __aligned__.
TIL that GCC has a __warn_if_not_aligned__ attribute now,
which could be useful, but mostly for the code that makes
these assumptions, so not us here.
padding. If all of them get fixed alignment, this would allow
switching -malign-int on independently for userspace and
kernel without changing the ABI. Any duplicated copies of
the struct definitions in userspace of course would need
the same changes.
That is… an interesting side effect and probably a good idea
to decouple this… unless there are any *other* kernel-side
changes we absolutely need for this that we don’t want to put
atop via evolution, not revolution (i.e. whether there is any‐
thing in the kernel/userspace boundary that direly needs to
change, for this or anyway, and is a breaking change… though
maybe even then).
On Sun, 27 Oct 2024, Greg Ungerer wrote:
There is plenty of Linux on ColdFire, but all the m68k'isms apply the same.
Ah, okay. All of it nommu though?
Is there anything special we need to do or must not to that
relates to ColdFire? Anyone to put in the Cc list for that?
... You don’t understand the problem: applications are being written
that require natural alignment for at least 32-bit and smaller
quantities, some possibly for all quantities even. We need these applications to work, and we cannot redesign them (it’s common for them
to store flags in the lowest pointer bits and do other awful things).
Could you please, if you cannot believe it yourself, accept the word of those actually doing the porting that it is direly needed in the current Linux ecosystem. Thank you.
For Debian, we have superh and i386, out of these.
On Okt 25 2024, Arnd Bergmann wrote:
Doing it without a migration path seems worse to me,
as this would mean breaking every single existing
installation between two kernels, and making it impossible
to bisect other issues, and breaking the rule #1.
That's why I didn't change the alignment when I implemented ELF. It
would have made it impossible to mix an a.out kernel with ELF user
space, and vice versa.
On Okt 25 2024, Thorsten Glaser wrote:
Question is, do we need a kernel change for this at all?
Is there anything in the kernel/userland interface that
gets affected by this, or do these APIs use sufficient
explicit padding? Has anyone looked at this?
Already basic things like struct stat64 will break.
https://marc.info/?l=glibc-help&m=169303990426196&w=2
On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote:
as m68k has supported 32-bit alignment through the "-malign-int"
switch for a long time.
That switch constitutes a fundamental ABI change, even if
the effect is limited.
Question is, do we need a kernel change for this at all?
Is there anything in the kernel/userland interface that
gets affected by this, or do these APIs use sufficient
explicit padding? Has anyone looked at this?
If we know that the answer is no, the plan could look
different from a yes answer, so…
Additionally… has anyone done the simple “enable -malign-int
in GCC, begin rebuilding stuff, first glibc, then others,
see what breaks”? Is there sufficient effect that we cannot
incrementally change over?
(Another question: does -malign-int switch to natural
alignment for all types, i.e. 64 bit for llong and double,
etc. or are we going to have to change GCC first as well
to avoid more surprises?)
On Fri, Oct 25, 2024 at 11:38 PM Thorsten Glaser <[email protected]> wrote:
Additionally… has anyone done the simple “enable -malign-int
in GCC, begin rebuilding stuff, first glibc, then others,
see what breaks”? Is there sufficient effect that we cannot
incrementally change over?
I guess there is code out there that checks for e.g. __mc68000__
and will start doing the wrong thing...
That seems to imply that someone requires that those packages are ported.
Yes, we do. Rust especially is killing the entire FOSS ecosystem.
These all are conditio sine qua nōn when it comes to continuing
Linux/m68k, as a whole.
Absent the right conditions, perhaps it is best focus limited porter and developer effort on patching only those packages that are really required.
I tried my hand at Qt5. About 20 man-hours in I essentially gave up,
and that was without even getting to something I could put to a
compile and runtime test.
“Natural” alignment of data types has essentially become a requirement these days, and m68k is the only true outlyer (i386 could in theory, but
the Unix psABI designers were sensible enough to not do it).
I think that's overstating the case. Alternatives to rust are available
and will be for the foreseeable future. Most notably, https://safecpp.org/draft.html
https://people.debian.org/~glaubitz/alignment-meme.jpg
I agree with your sentiment though, in that rust generally gets a lot of funding and hype. Even if the Rust Foundation doesn't care about
supporting the backend for m68k, there is still a way for non-commercially viable platforms to collaborate. In particular, https://gcc.gnu.org/wiki/RustFrontEnd
Absent the right conditions, perhaps it is best focus limited porter and developer effort on patching only those packages that are really required.
I tried my hand at Qt5. About 20 man-hours in I essentially gave up,
and that was without even getting to something I could put to a
compile and runtime test.
I take your point about the amount of effort required (and the lack of resources). The answer may be to share the work better by enabling more collaboration.
It appears that NetBSD/m68k has naturally aligned ints. Perhaps you could look at adding kernel support for their ABI, and get access to Qt and LLVM that way, without impacting the existing ABI and its ecosystem.
BTW, it has long annoyed me that two different 68k Mac bootloaders exist, one each for Linux and NetBSD, which are duplicated effort, and have different sets of bugs. To my mind, this is another good opportunity to collaborate and avoid wasted developer effort (perhaps by dual licensing).
“Natural” alignment of data types has essentially become a requirement these days, and m68k is the only true outlyer (i386 could in theory, but the Unix psABI designers were sensible enough to not do it).
I expect alignment assumptions like that will end up putting more
platforms in the same predicament in future. "Natural" alignment is meaningless in the context of portable data structures, as they exist without reference to any particular integer unit. It is because your
struct patches improve portability that I'd expect those patches to remain acceptable upstream.
Q. What is the size of this struct, assuming baa.b is naturally aligned?
struct baa {
int a;
long long b;
};
I think that's overstating the case. Alternatives to rust are available and will be for the foreseeable future. Most notably,
That’s not the point. Google, for example, are aggressively funding
people to throw away perfectly working code and rewrite it in rust,
or to at least add rust to projects. librsvg has been such a case for
some time already, python-cryptography is, but now we’re losing even freetype (!!!) and, possibly, even the Linux kernel.
https://gcc.gnu.org/wiki/RustFrontEnd
That’s assuming it can build the same stuff the same way so it can
be used in packaging.
https://buildd.debian.org/status/fetch.php?pkg=python3.13&arch=m68k&ver=3.13.0-1&stamp=1728344123&raw=0
I expect alignment assumptions like that will end up putting more platforms in the same predicament in future.
No, all the other platforms use natural alignment.
"Natural" alignment is meaningless in the context of portable data structures, as they exist without reference to any particular integer
Yeah, but in practice, all we have is ILP32 and LP64; the Windows®
world has LLP64 in addition. And natural alignment just means that
all the data types’ alignment is their size. (Which kind of makes
sense, so you can read them without getting an unalignment trap on
SPARC or so.)
Q. What is the size of this struct, assuming baa.b is naturally aligned?
struct baa {
int a;
long long b;
};
For ILP32, LP64 and LLP64, it’s 4 (a) + 4 (padding) + 8 (b) = 16 chars. More importantly, and relevant for Qt, struct baa is also 8-byte
aligned, and malloc(3) results are usually 8‑ or even 16-byte aligned.
On Sun, Oct 27, 2024, at 06:16, Finn Thain wrote:
On Sun, 27 Oct 2024, Thorsten Glaser wrote:
Finn Thain dixit:
That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the case on my Linux/i686 system. 4 != 8:
struct baa {
int a;
long long b;
} foo;
That struct is just 12 bytes for you then?
Right. i686 and m68k agree on that.
The other ones that have misaligned 'long long' variables are
arc
arm (OABI only)
csky
microblaze
nios2
openrisc
superh
i386
The 32-bit architectures that use a natural 8-byte
alignment are
arm (EABI)
parisc
mips
powerpc
riscv
s390
sparc
xtensa
m68k is the only architecture supported by linux-6.x that
does 2-byte alignment, otherwise the two seem to be equally
common.
On Sun, 27 Oct 2024, Thorsten Glaser wrote:
https://gcc.gnu.org/wiki/RustFrontEnd
That’s assuming it can build the same stuff the same way so it can be used in packaging.
Not an assumption. I simply pointed out an opportunity for collaboration, because I see the primary problem facing the m68k port is a lack of resources.
I expect alignment assumptions like that will end up putting more platforms in the same predicament in future.
No, all the other platforms use natural alignment.
"Natural" alignment is meaningless in the context of portable data structures, as they exist without reference to any particular integer
Yeah, but in practice, all we have is ILP32 and LP64;
... for now.
the Windows® world has LLP64 in addition. And natural alignment just means that all the data types’ alignment is their size. (Which kind of makes sense, so you can read them without getting an unalignment trap on SPARC or so.)
That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the
case on my Linux/i686 system. 4 != 8:
struct baa {
int a;
long long b;
} foo;
Q. What is the size of this struct, assuming baa.b is naturally aligned?
struct baa {
int a;
long long b;
};
For ILP32, LP64 and LLP64, it’s 4 (a) + 4 (padding) + 8 (b) = 16 chars.
So natural alignment is portable if you first assume a data model. But the struct definition itself is not portable, since it doesn't specify a data model.
More importantly, and relevant for Qt, struct baa is also 8-byte
aligned...
If the struct itself is not naturally aligned, it too will eventually
break someone's assumption of natural alignment.
You talk about "applications ... being written". Well, two days ago I mentioned several groups of applications: (1) core packages that accept alignment patches, (2) packages whose developers shouldn't worry about
small systems anyway, and (3) packags I am concerned about i.e. the ones actually required by Debian/m68k users (which will presumably lead to
disto bug reports, if they didn't already -- hence my question about bug reports which remains unanswered).
For Debian, we have superh and i386, out of these.
Is your concern merely for Debian's package archive stats?
What interests me is portability and code reuse in general. That is the basis on which I would send alignment patches to upstream projects.
On Sun, 27 Oct 2024, Arnd Bergmann wrote:
On Sun, Oct 27, 2024, at 06:16, Finn Thain wrote:
Right. And I don't think the problem is going to go away. One solution that is sometimes raised is better tooling. I'm not sure how that would
No. You don’t understand the problem: applications are being
written that require natural alignment for at least 32-bit and
smaller quantities, some possibly for all quantities even. We
need these applications to work, and we cannot redesign them
(it’s common for them to store flags in the lowest pointer bits
and do other awful things).
Could you please, if you cannot believe it yourself, accept the
word of those actually doing the porting that it is direly needed
in the current Linux ecosystem. Thank you.
That struct is just 12 bytes for you then?
Right. i686 and m68k agree on that.
The other ones that have misaligned 'long long' variables are
arc
arm (OABI only)
csky
microblaze
nios2
openrisc
superh
i386
Okaaay. So, all “old” platforms or with low distro support.
For Debian, we have superh and i386, out of these. It is
entirely possible that Qt et al. can work with this, but
these all have natural alignment for quantities ≤ 32 bits.
Does Gentoo support more of them? Debian used to have arm
OABI, but that’s ages ago. I know things like OpenADK support
them, but that is very chiefly embedded.
The 32-bit architectures that use a natural 8-byte
alignment are
arm (EABI)
parisc
mips
powerpc
riscv
s390
sparc
xtensa
That’s majoritily represented in Debian. And ideally, we’d
use that for all new architectures.
I have a feeling that GCC’s -malign-int will only push us
into the former. I have no idea whether it’s feasible to
also change GCC for this; that will probably depend on both
the other “what parts of the toolchain need changing” and
whether GCC can be switched with little effort.
https://marc.info/?l=glibc-help&m=169303990426196&w=2
What ecosystem? Do you honestly care that any hobbyist cares about
having to reinstall their retro computers?
That seems to imply that someone requires that those packages are
ported. But without a bug report from such a user, to say the package
is broken or missing, one must question the real requirement.
People have tried this in the past and it was an endless effort. It's
not that it hasn't been tried. And there is zero chance that any of
these projects accept such patches to support unusual alignment.
It's not that I'm not speaking from experience having maintained the
m68k port in Debian the past 10 years. The Gentoo folks will tell you
the same.
Those are the most important projects from the tip of my head, but
they are already the biggest blockers. There is no chance that the upstream maintainers will adjust their packages for 16-bit
alignment, so these will be forever broken on m68k if we don't
switch.
I'm curious to see such a refusal in context, presumably as a result
of patch review, in an upstream project bug tracker.
I'm not actually expecting to see good patches refused by core
projects like Python. (Note that MicroPython is available for
commercially active CPUs like the PIC16 family, which are 8-bit
processors with 16-bit address bus.)
Why does my word not count here? It's not that this problem is new.
You can also ask Andreas who maintained openSUSE on m68k for a while and
had to carry lots of local patches.
If upstream QT or Java developers decide that their software is "not
for us", they may well have a point. Those packages are not installed
on my m68k systems, FWIW.
This is isn't just about runtime dependencies but also build
dependencies which is why I linked the statistics page in Debian. A lot
of packages in Debian/m68k can currently not be built because they have
a transitive dependency on Rust, OpenJDK, Qt, GNOME and so on.
OTOH, as I've said before, if upstream developers (like Arnd) are
looking ahead to 128-bit platforms then they will be paying attention
to alignment rules. They should be inclined to favour explicit struct definitions over implicit alignment, don't you think?
Debian just transitioned all of their 32-bit architectures to time64_t
except for i386. Do you know why they did that even though 128-bit CPUs
are practically around the corner?
I understand that this might be a painful transition, but I don't
see any other way to keep the m68k port alive in the foreseeable
future unless we fix this problem which keeps blocking the port.
You can see how the Debian m68k port has been falling behind because
of the alignment issues in these statistics: https://buildd.debian.org/stats/graph-ports-big.png
I could imagine a viable transition to a new ABI driven by widespread
user demand or involvement. But not by distro stats or maintainer preference.
Well, I'm doing the work, so I get to make the decisions here, no?
Absent the right conditions, perhaps it is best focus limited porter
and developer effort on patching only those packages that are really required.
Thanks, but I tried that and it doesn't work. I don't want to continue spending hours on trying to figure out how to fix alignment problems and
then maybe send an email here and there to just never get an answer.
You're somehow implying that I'm requesting this change because I'm just lazy.
For Debian, we have superh and i386, out of these. It is entirely
possible that Qt et al. can work with this, but these all have natural alignment for quantities ≤ 32 bits.
I'm not aware of any serious issues with alignment on i386.
i386 was the original target for 90% of the software in Debian, so if
there are issues, developers have already addressed them.
On 25/10/24 22:55, Arnd Bergmann wrote:
I also expect that a lot of users (of m68k kernels) are never going to
get the benefits as they are already stuck on older userspace because
of added bloat in new software releases. I assume you have better understanding than me of what m68k hardware is commonly used these
days, and how constrained that is in practice.
I second that - currently bisecting to find out what makes my extremely
RAM constrained m68k system fail to boot or run anything past 6.9-rc4 (sysvinit, not systemd).
Much as I appreciate Adrian's efforts to keep up with user space
development, I won't be in a position to help with an ABI change.
On Tue, 29 Oct 2024, Michael Schmitz wrote:
On 25/10/24 22:55, Arnd Bergmann wrote:
I also expect that a lot of users (of m68k kernels) are never going to get the benefits as they are already stuck on older userspace because
of added bloat in new software releases. I assume you have better understanding than me of what m68k hardware is commonly used these
days, and how constrained that is in practice.
I second that - currently bisecting to find out what makes my extremely RAM constrained m68k system fail to boot or run anything past 6.9-rc4 (sysvinit, not systemd).
As cloud instances multiply, that small quantity of lost RAM gets multiplied. So it appears that small systems aren't so strange, even after they become unprofitable...
Much as I appreciate Adrian's efforts to keep up with user space development, I won't be in a position to help with an ABI change.
Bloated m68k packages will continue to work -- given emulators that run faster with every hardware upgrade. But how would such a distro add value?
I don't mind if Gentoo ships a separate profile for (downstream) ABI experimentation, leaving the default m68k profile on the standard ABI.
And if Debian wants to switch ABI entirely, I won't object further, I've said enough about the associated risks.
So I'll just reiterate that I'd rather see more collaboration instead -
1) among all small systems ports, to try to alleviate Debian's package
dependency problem
2) among all developers working on non-commercial architectures, to
improve the GCC Rust frontend
3) among all 680x0 developers interested in the NetBSD ABI
4) among all users of EOL'd hardware, so that value may continue to be
extracted from it (thanks to the efforts of Debian and Gentoo devs,
among others).
On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:
That seems to imply that someone requires that those packages are ported. But without a bug report from such a user, to say the package
is broken or missing, one must question the real requirement.
People have tried this in the past and it was an endless effort. It's
not that it hasn't been tried. And there is zero chance that any of
these projects accept such patches to support unusual alignment.
Then don't leave it to chance.
Why does my word not count here? It's not that this problem is new.
Your opinion does not count here because the question was about upstream patch refusals. I'm genuinely interested to see the patch reviews. After all, many alignment patches have already been merged.
Without being able to see the actual response from upstream developers, I can only assume that they have either misunderstood the issue or they have simply decided their users would not be served by an m68k port. Do you
agree that upstream developers generally know their users requirements better than distros do?
You can also ask Andreas who maintained openSUSE on m68k for a while and had to carry lots of local patches.
If upstream QT or Java developers decide that their software is "not
for us", they may well have a point. Those packages are not installed
on my m68k systems, FWIW.
This is isn't just about runtime dependencies but also build
dependencies which is why I linked the statistics page in Debian. A lot
of packages in Debian/m68k can currently not be built because they have
a transitive dependency on Rust, OpenJDK, Qt, GNOME and so on.
That's one reason why source distros are a better fit for small systems
than binary distros are. You can't fix this basic problem with an ABI change.
OTOH, as I've said before, if upstream developers (like Arnd) are looking ahead to 128-bit platforms then they will be paying attention
to alignment rules. They should be inclined to favour explicit struct definitions over implicit alignment, don't you think?
Debian just transitioned all of their 32-bit architectures to time64_t except for i386. Do you know why they did that even though 128-bit CPUs are practically around the corner?
Perhaps they have explained their actions? Do you have an opinion?
I understand that this might be a painful transition, but I don't
see any other way to keep the m68k port alive in the foreseeable future unless we fix this problem which keeps blocking the port.
You can see how the Debian m68k port has been falling behind because of the alignment issues in these statistics: https://buildd.debian.org/stats/graph-ports-big.png
I could imagine a viable transition to a new ABI driven by widespread user demand or involvement. But not by distro stats or maintainer preference.
Well, I'm doing the work, so I get to make the decisions here, no?
Sure. Please refer to my previous email about the m68k ABI du jour and fragmentation.
Absent the right conditions, perhaps it is best focus limited porter
and developer effort on patching only those packages that are really required.
Thanks, but I tried that and it doesn't work. I don't want to continue spending hours on trying to figure out how to fix alignment problems and then maybe send an email here and there to just never get an answer.
You're somehow implying that I'm requesting this change because I'm just lazy.
You're somehow twisting my words into a slur. You know that I value your alignment patches because I've said so before. Thanks again for your efforts.
Arnd,
On 25/10/24 22:55, Arnd Bergmann wrote:
I also expect that a lot of users (of m68k kernels) are
never going to get the benefits as they are already stuck on
older userspace because of added bloat in new software
releases. I assume you have better understanding than me
of what m68k hardware is commonly used these days, and
how constrained that is in practice.
I second that - currently bisecting to find out what makes my extremely
RAM constrained m68k system fail to boot or run anything past 6.9-rc4 (sysvinit, not systemd).
Much as I appreciate Adrian's efforts to keep up with user space development, I won't be in a position to help with an ABI change.
Much as I appreciate Adrian's efforts to keep up with user spaceThanks, I will then just do it myself with brute force or drop the port.
development, I won't be in a position to help with an ABI change.
Adrian
Look at it philosophically. One path is to dig in and try to change as little as possible to keep the oldest systems working.
The other is to do your best to adapt to keep the greatest relevant to modern development.
I didn't say that - just supporting Arnd's point that much of the RAM constrained old m68k software won't benefit from today's user space.
Development isn't driven by memory pressure anymore, so code bloat is a natural consequence.
What such hardware would benefit from is low memory optimized user
space. That's hard to do with Debian, as bloat appears to have crept
into the build dependencies chain (if I understand you correctly).
While Debian was the first Linux distribution to support m68k, these days there are other options, maybe some better suited to low memory systems
(and I'd consider even 256 MB on Amiga 'low memory' ...).
Much as I appreciate Adrian's efforts to keep up with user space development, I won't be in a position to help with an ABI change.Thanks, I will then just do it myself with brute force or drop the port.
Sure, you do pretty much all the work on Debian/68k, so you get to decide.
If this involves changes at kernel level (syscall parameter alignment?) however, my recommendation would be to rather drop the port than end up
with new kernels no longer backwards compatible with old user space.
Otherwise, I'd not even be in a position to do any kernel testing and bugfixing (which often requires hardware, not emulators).
But we're not really suffering from bloat. On the contrary, both software like systemd or Rust-compiled software actually use less memory, not more.
Well, systemd is completely useless on every 68030 and 68040 Mac that I
own, even ones that have enough memory to run it (e.g. SE/30, IIfx and Centris 650). It takes most of its time just telling me about all of the things that are timing out. It fires off too many concurrrent processes
that overwhelm slow CPUs. Whenever systemd becomes a hard requirement in Debian, I won't be using Debian at all (there are still GNU/Linux distributions such as Gentoo that do not require systemd).
SysVInit uses a huge set of bash scripts where every action involves spawning
a new shell while systemd does all of that in C. Compiled C code is definitely
faster on an m68k machine than hundreds of shell scripts.
Yes, compiled C code is faster than an equivalent script, but scripts
are much easier (for some of us) to edit and turn on and off than
systemd components.
Plus systemd has lots of components and does lots of things that arguably
an init system shouldn't even be doing, things that aren't needed at all
on old systems, such as managing logins, setting the time and managing DNS.
Systemd even complains if I manually edit /etc/fstab.
Perhaps there are ways to tune systemd for small systems,
but I haven't seen any distribution that does that. On small, static
systems that don't have USB, Firewire, PC-Cards, etc., udevd and
sometimes dbus aren't even needed, and systemd is certainly overkill for
such systems.
I'm not trying to rehash old systemd/sysvinit discussions; I realize
that Debian has chosen systemd as its default init system. That's fine; Debian can do whatever they want, but no one can tell me that systemd,
at least in the configuration as it is distributed by Debian, is better
than sysvinit for small, mostly static systems. That's why there are
entire distributions that are dedicated specifically to not forcing
their users to use systemd.
https://lwn.net/Articles/786593/
What such hardware would benefit from is low memory optimized user space. That's hard to do with Debian, as bloat appears to have crept into the build dependencies chain (if I understand you correctly).
The build dependencies don't end up on the installed system. For example, if
Java code is used to generate documentation, the Java runtime won't have to be installed on the target machine. But you still need a working OpenJDK
to be able to build such packages.
While Debian was the first Linux distribution to support m68k, these days
there are other options, maybe some better suited to low memory systems (and I'd consider even 256 MB on Amiga 'low memory' ...).
Well, I'd consider 16 MiB to be "low memory" for 68030 Macs, but you are
the Debian m68k port maintainer so you can consider whatever you want to
be low memory. Hopefully the bloat (Linux kernel and applications) will
be minimized so that old Macs, such as 68030 PowerBooks and desktops
that can have no more than 36 MiB, will be able to continue running, not
just Amigas that have 256 MiB memory. If we're headed toward Linux distributions that can only run well enough in QEMU or Aranym, what's
the point in having old systems at all?
Sure, you do pretty much all the work on Debian/68k, so you get to decide.
If this involves changes at kernel level (syscall parameter alignment?) however, my recommendation would be to rather drop the port than end up with new kernels no longer backwards compatible with old user space.
Otherwise, I'd not even be in a position to do any kernel testing and bugfixing (which often requires hardware, not emulators).
I don't buy this argument. Why would your world fall apart if we switch alignment to 4 bytes. I seriously don't get it.
On Thu, 2024-11-14 at 07:36 +1300, Michael Schmitz wrote:
I didn't say that - just supporting Arnd's point that much of the RAM
constrained old m68k software won't benefit from today's user space.
We're talking about an open source stack here. No one is going to run an
old binary from the 80s on a current system. And if you want to run old >software, you're certainly also not running the latest kernel.
SysVInit uses a huge set of bash scripts where every action involves spawning
Again, the problem is not Debian-specific. Heck, it's not even Linux-specific.
If this involves changes at kernel level (syscall parameter alignment?)
however, my recommendation would be to rather drop the port than end up
with new kernels no longer backwards compatible with old user space.
On Mon, 2024-10-28 at 19:40 +1100, Finn Thain wrote:
On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:
What ecosystem? Do you honestly care that any hobbyist cares about
having to reinstall their retro computers?
The issue is not just old binaries. You made the same mistake in your message to Arnd when you said "we're not allowed to fix that [ABI] because someone might run an old binary". For some reason you're choosing to
ignore numerous objections that have been covered on the mailing lists to date.
I have only seen real objections from your side. Everyone else agrees
that future development of the platform is not feasible without making
the switch.
Then don't leave it to chance.
What is supposed to mean? Are you implying that I never tried to address this?
Did you have a try at fixing any of these?
A lot of packages in Debian/m68k can currently not be built because
they have a transitive dependency on Rust, OpenJDK, Qt, GNOME and so
on.
That's one reason why source distros are a better fit for small
systems than binary distros are. You can't fix this basic problem with
an ABI change.
Gentoo has the same problem with Linux m68k and they want to perform the switch as well. So it's not just my personal opinion here.
Well, I'm doing the work, so I get to make the decisions here, no?
Sure. Please refer to my previous email about the m68k ABI du jour and fragmentation.
What fragmentation? The vast majority of people interested in this architecture want to progress and not keep the status quo forever. And
the switch is simply inevitable which is why Chewi has pitched a
proposal on this list as well.
Absent the right conditions, perhaps it is best focus limited
porter and developer effort on patching only those packages that
are really required.
Thanks, but I tried that and it doesn't work. I don't want to
continue spending hours on trying to figure out how to fix alignment problems and then maybe send an email here and there to just never
get an answer.
You're somehow implying that I'm requesting this change because I'm
just lazy.
You're somehow twisting my words into a slur. You know that I value
your alignment patches because I've said so before. Thanks again for
your efforts.
Look, the problem is that this is a) an endless effort and b) in some
cases simply not feasible. Codebases like LLVM are completely built
around a natural alignment of at least four bytes and it's simply
impossible to work around that.
There are so many other things I would like to work on and I simply
consider it a waste of time and resources to work on the same problem
over and over again just because we cannot agree on finally fixing the underlying issue.
As of now, Debian/m68k will miss the transition to Python 3.13 because
the new version requires 4-byte alignment and absolutely no one is
willing to help me fix this issue.
3) among all 680x0 developers interested in the NetBSD ABI
The alignment issue affects NetBSD as well.
But, as has been pointed out, if we make the current alignment explicit everywhere, the kernel ABI does not have to change¹. And new syscalls, ioctls, structs, etc. can just be made with natural alignment in mind (I
bet most are already anyway) and with padding assumptions made expli‐
cit (which again probably is done already anyway).
On Sun, 27 Oct 2024, Thorsten Glaser wrote:
Finn Thain dixit:
That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the >case on my Linux/i686 system. 4 != 8:
struct baa {
int a;
long long b;
} foo;
That struct is just 12 bytes for you then?
Right. i686 and m68k agree on that.
On Thu, 2024-11-14 at 07:36 +1300, Michael Schmitz wrote:
Development isn't driven by memory pressure anymore, so code bloat is a natural consequence.
But we're not really suffering from bloat. On the contrary, both software
like systemd or Rust-compiled software actually use less memory, not more.
While Debian was the first Linux distribution to support m68k, these days there are other options, maybe some better suited to low memory systems (and I'd consider even 256 MB on Amiga 'low memory' ...).
On 11/13/24 2:01 PM, John Paul Adrian Glaubitz wrote:
a new shell while systemd does all of that in C. Compiled C code is definitelySysVInit uses a huge set of bash scripts where every action involves spawning
faster on an m68k machine than hundreds of shell scripts.
Yes, compiled C code is faster than an equivalent script, but scripts
are much easier (for some of us) to edit and turn on and off than
systemd components.
systemctl disable foo.service is too hard?
Yes, it's too hard. And if I want to change something in foo.service
instead of disabling it, I'm sure there's a way to do that in systemd as well, but using vi (or nano) to edit the equivalent sysvinit script is
easier for some of us. Also, if fubar.service is completely messed up,
then I might not be able to boot into the operating system that is
running systemd in order to use systemctl (especially on a slow system).
On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote:
as m68k has supported 32-bit alignment through the "-malign-int"
switch for a long time.
That switch constitutes a fundamental ABI change, even if
the effect is limited.
Question is, do we need a kernel change for this at all?
Is there anything in the kernel/userland interface that
gets affected by this, or do these APIs use sufficient
explicit padding? Has anyone looked at this?
(Another question: does -malign-int switch to natural
alignment for all types, i.e. 64 bit for llong and double,
etc. or are we going to have to change GCC first as well
to avoid more surprises?)
On i686 (i.e. gcc -m32 on amd64):
__alignof__(long long) = 8
but
sizeof(struct baa) = 12
__alignof__(struct baa) = 4
???
Isn't the alignment of a struct the largest alignment of any of its
members?
(Another question: does -malign-int switch to natural
alignment for all types, i.e. 64 bit for llong and double,
etc. or are we going to have to change GCC first as well
to avoid more surprises?)
It only changes alignment for short and larger from 2 to 4 bytes.
So long long and double are still aligned to 4 bytes instead of 8.
If we decide to change alignment, I'd rather change all types to
natural alignment, to avoid future nasty surprises.
What to do with long double, which is 12 bytes on m68k and i386?
I386 kept its alignment at 4, while amd64 changed both size and
alignment to 16.
On Sun, Oct 27, 2024 at 7:16 AM Finn Thain <[email protected]> wrote:
On Sun, 27 Oct 2024, Thorsten Glaser wrote:
Finn Thain dixit:
That would mean __alignof__(foo.b) == sizeof(foo.b) but that's not the >case on my Linux/i686 system. 4 != 8:
struct baa {
int a;
long long b;
} foo;
That struct is just 12 bytes for you then?
Right. i686 and m68k agree on that.
On i686 (i.e. gcc -m32 on amd64):
__alignof__(long long) = 8
but
sizeof(struct baa) = 12
__alignof__(struct baa) = 4
???
Isn't the alignment of a struct the largest alignment of any of its members?
On NetBSD/m68k I get,
sizeof(struct baa) == 16
__alignof__(long long) == 8
__alignof__(struct baa) == 8
Isn't the alignment of a struct the largest alignment of any of its members?
Sometimes...
tg@fish:~ $ ./a.out
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 715 |
| Nodes: | 16 (3 / 13) |
| Uptime: | 43:07:55 |
| Calls: | 12,111 |
| Calls today: | 2 |
| Files: | 15,008 |
| Messages: | 6,518,438 |
