Plan needed for switching m68k to 32-bit alignment

Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

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.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

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?

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

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

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[Arnd Bergmann]

On Fri, Oct 25, 2024, at 06:48, John Paul Adrian Glaubitz wrote:
> 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.

Hi Adrian,

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.

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.

Examples of other ABI changes we had in the kernel are:

- ARM EABI was added before the architecture became
  dominant, and ended up as a success. The structure
  alignment differences between OABI and EABI were part of
  it, but it was mostly pushed because of Thumb
  instruction support, and with a huge investment of
  development resources.

- PowerPC ELFv2 was a similar success, this one was driven
  by a strong desire to allow little-endian distros, and
  again was done with a very significant investment.
  
- MIPS/n32 and x86/x32 never took off despite the effort
  put into them and the advantages for both the ABI and
  performance compared to running traditional 32-bit
  binaries on 64-bit kernels. As I understand, gentoo
  still supports both, so clearly someone likes these, but
  from a kernel perspective they still cause us headache
  and were clearly a mistake. Attempts to do the same
  on powerpc/arm64/riscv64 were rejected for these reasons.

- The big-endian ABIs for arm and arm64 were mostly a
  complete failure, having been pushed for by network
  SoC makers (Intel IXP mainly) before that industry moved
  to little-endian. Adding these made a lot of sense at
  the time when big-endian powerpc and mips owned that
  market but has since turned into a liability. Nowadays
  it's mainly used for regression-testing big-endian mode
  on widely available hardware (arm64 VM guests).

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.

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.

       Arnd

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

Hi Arnd,

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.

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

Users with very slow hardware and without accelerators aren't
going to run a modern kernel anyway, so this argument is moot.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[Arnd Bergmann]

On Fri, Oct 25, 2024, at 10:10, John Paul Adrian Glaubitz wrote:
> 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.

Changing all system call numbers and a lot of the ioctl
structures definitely makes it a new ABI, regardless of
how much it affects general userspace, and does require a
complete bootstrap of the distro.

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

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.

It's probably not necessary to support both user ABIs
in a single kernel image, but a kernel compile-time switch
would seem appropriate.

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

Understood.

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

I'm not worried about ancient binaries, and I think a 10 year
transition period like in ARM-EABI or PPC64/ELFv2 would be
fine, but breaking all users from one release to the next
is a clear show-stopper.

      Arnd

Re: Plan needed for switching m68k to 32-bit alignment

[Andreas Schwab]

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.

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

Re: Plan needed for switching m68k to 32-bit alignment

[Thorsten Glaser]

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

bye,
//mirabilos
-- 
Solange man keine schmutzigen Tricks macht, und ich meine *wirklich*
schmutzige Tricks, wie bei einer doppelt verketteten Liste beide
Pointer XORen und in nur einem Word speichern, funktioniert Boehm ganz
hervorragend.		-- Andreas Bogk über boehm-gc in d.a.s.r

Re: Plan needed for switching m68k to 32-bit alignment

[Andreas Schwab]

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.

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

Re: Plan needed for switching m68k to 32-bit alignment

[Thorsten Glaser]

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
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
	-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

On Fri, 25 Oct 2024, John Paul Adrian Glaubitz wrote:

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

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.

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

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.

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?

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

Absent the right conditions, perhaps it is best focus limited porter and 
developer effort on patching only those packages that are really required.

Re: Plan needed for switching m68k to 32-bit alignment

[Geert Uytterhoeven]

Hi Thorsten,

On Fri, Oct 25, 2024 at 11:38 PM Thorsten Glaser <tg@debian.org> 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...

Gr{oetje,eeting}s,

                        Geert

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

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

Re: Plan needed for switching m68k to 32-bit alignment

[Thorsten Glaser]

On Sat, 26 Oct 2024, Finn Thain wrote:

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

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

bye,
//mirabilos
-- 
<igli> exceptions: a truly awful implementation of quite a nice idea.
<igli> just about the worst way you could do something like that, afaic.
<igli> it's like anti-design.  <mirabilos> that too… may I quote you on that?
<igli> sure, tho i doubt anyone will listen ;)

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

[-- Attachment #1: Type: text/plain, Size: 2545 bytes --]


On Sun, 27 Oct 2024, Thorsten Glaser wrote:

> >
> >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://safecpp.org/draft.html

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;
};

Re: Plan needed for switching m68k to 32-bit alignment

[Thorsten Glaser]

Finn Thain dixit:

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

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.

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

bye,
//mirabilos
-- 
Gestern Nacht ist mein IRC-Netzwerk explodiert. Ich hatte nicht damit
gerechnet, darum bin ich blutverschmiert… wer konnte ahnen, daß SIE so
reagier’n… gestern Nacht ist mein IRC-Netzwerk explodiert~~~
	(as of 2021-06-15 The MirOS Project temporarily reconvenes on OFTC)

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

[-- Attachment #1: Type: text/plain, Size: 1797 bytes --]


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.

Re: Plan needed for switching m68k to 32-bit alignment

[Thorsten Glaser]

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.

bye,
//mirabilos
-- 
If Harry Potter gets a splitting headache in his scar
when he’s near Tom Riddle (aka Voldemort),
does Tom get pain in the arse when Harry is near him?
	-- me, wondering why it’s not Jerry Potter………

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

[-- Attachment #1: Type: text/plain, Size: 1827 bytes --]


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.

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

Well, the GCC manual says the Power architecture also has ABI variants 
with differing alignment rules.

https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/RS_002f6000-and-PowerPC-Options.html#index-malign-natural
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/x86-Options.html#index-malign-data-1
https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/x86-Options.html#index-malign-double

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

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 
work. Perhaps a better solution would be language changes to allow a 
struct definition to be qualified with an explicit 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.
> 
> 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.
> 

Makes sense.

Re: Plan needed for switching m68k to 32-bit alignment

[Arnd Bergmann]

On Fri, Oct 25, 2024, at 22:24, Andreas Schwab wrote:
> 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.

I tried writing a small script that compiles each exported
kernel header in order to get the debugging data for struct
definitions. This is the list of the 236 structures that
pahole reports being different with -malign-int. I probably
missed a small number in header files that failed to build
standalone, but this covers most.

I think it makes sense to go through these anyway and annotate
them to document and enforce the alignment we actually want
regardless of -malign-int, either by adding architecture
specific __packed/__aligned attributes, or by adding explicit
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.

      Arnd

---
 struct _IOCTL_Command_struct {
 struct _MGSL_PARAMS {
 struct __fat_dirent {
 struct __old_kernel_stat {
 struct acrn_cstate_data {
 struct acrn_pcidev {
 struct atm_backend_ppp {
 struct atm_qos {
 struct atm_trafprm {
 struct atmlec_config_msg {
 struct atmlec_ioc {
 struct atmlec_msg {
 struct atmsvc_msg {
 struct atmtcp_control {
 struct ax25_ctl_struct {
 struct ax25_route_opt_struct {
 struct blk_user_trace_setup {
 struct bpf_perf_event_data {
 struct bpq_req {
 struct br_mdb_entry {
 struct br_mrp_in_role {
 struct br_mrp_in_state {
 struct br_mrp_instance {
 struct br_mrp_start_in_test {
 struct br_port_msg {
 struct btrfs_ioctl_dev_replace_args {
 struct btrfs_ioctl_dev_replace_start_par
 struct cdrom_blk {
 struct cdrom_generic_command {
 struct cdrom_multisession {
 struct cdrom_read_audio {
 struct cdrom_subchnl {
 struct cdrom_tocentry {
 struct cycx_firmware {
 struct cycx_fw_info {
 struct dlm_lksb {
 struct dlm_lock_result {
 struct drm_etnaviv_pm_signal {
 struct dvb_diseqc_slave_reply {
 struct dvd_bca {
 struct dvd_lu_send_title_key {
 struct dvd_manufact {
 struct dvd_physical {
 struct ebt_arp_info {
 struct ebt_arpreply_info {
 struct ebt_mark_m_info {
 struct ebt_nat_info {
 struct ebt_stp_config_info {
 struct ebt_stp_info {
 struct edd {
 struct efs_super {
 struct eg_ctrl_info {
 struct ethtool_ah_espip4_spec {
 struct ethtool_ah_espip6_spec {
 struct ethtool_rx_ntuple_flow_spec {
 struct ethtool_tcpip4_spec {
 struct ethtool_tcpip6_spec {
 struct ethtool_usrip6_spec {
 struct ethtool_wolinfo {
 struct fat_boot_sector {
 struct fb_cursor {
 struct fb_fix_screeninfo {
 struct fb_image {
 struct floppy_drive_params {
 struct floppy_fdc_state {
 struct fs_quota_stat {
 struct full_sockaddr_ax25 {
 struct full_sockaddr_rose {
 struct hdr_output_metadata {
 struct hdsp_config_info {
 struct hdsp_version {
 struct hdspm_peak_rms {
 struct hdspm_status {
 struct hdspm_version {
 struct he_ioctl_reg {
 struct hiddev_devinfo {
 struct hv_kvp_msg {
 struct i2c_msg {
 struct i2c_smbus_ioctl_data {
 struct i2o_sw_xfer {
 struct idmap_msg {
 struct ieee_pfc {
 struct ifla_vf_vlan_info {
 struct in_ctrl_info {
 struct inet_diag_hostcond {
 struct ip6t_ah {
 struct ip6t_frag {
 struct ip6t_rt {
 struct ip6t_srh1 {
 struct ip_set_counter_match0 {
 struct ip_vs_dest_entry {
 struct ip_vs_dest_user {
 struct ip_vs_get_dests {
 struct ip_vs_service_entry {
 struct ip_vs_service_user {
 struct ipmi_addr {
 struct ipmi_ipmb_direct_addr {
 struct ipmi_ssif_msg {
 struct ipt_ah {
 struct ipt_clusterip_tgt_info {
 struct j1939_filter {
 struct k_message {
 struct loop_info {
 struct media_link_desc {
 struct media_pad_desc {
 struct mf6cctl {
 struct mfcctl {
 struct mif6ctl {
 struct msgbuf {
 struct msginfo {
 struct msqid_ds {
 struct mtd_info_user {
 struct mtop {
 struct nd_papr_pdsm_health {
 struct nd_papr_pdsm_smart_inject {
 struct nf_nat_range2 {
 struct nfs_mount_data {
 struct nr_route_struct {
 struct opal_geometry {
 struct ovs_action_push_mpls {
 struct ovs_key_arp {
 struct ovs_key_ct_tuple_ipv4 {
 struct ovs_key_ct_tuple_ipv6 {
 struct pci_endpoint_test_xfer_param {
 struct pg_read_hdr {
 struct pg_write_hdr {
 struct plipconf {
 struct pt_regs {
 struct ptrace_syscall_info {
 struct qedr_create_qp_uresp {
 struct rds6_info_rdma_connection {
 struct rds_info_rdma_connection {
 struct rio_rdev_info {
 struct rkisp1_cif_isp_afc_config {
 struct rkisp1_cif_isp_dpf_config {
 struct rkisp1_cif_isp_dpf_nll {
 struct rkisp1_cif_isp_isp_meas_cfg {
 struct rkisp1_cif_isp_isp_other_cfg {
 struct rkisp1_cif_isp_sdg_config {
 struct rkisp1_cif_isp_stat {
 struct rkisp1_ext_params_afc_config {
 struct rkisp1_ext_params_dpf_config {
 struct rkisp1_ext_params_sdg_config {
 struct rkisp1_params_cfg {
 struct rkisp1_stat_buffer {
 struct rose_facilities_struct {
 struct rtc_wkalrm {
 struct scc_calibrate {
 struct scc_modem {
 struct scom_access {
 struct semid_ds {
 struct serial_multiport_struct {
 struct serial_struct {
 struct sigcontext {
 struct sioc_mif_req6 {
 struct sioc_vif_req {
 struct sisfb_info {
 struct snd_dm_fm_note {
 struct snd_emu10k1_fx8010_pcm_rec {
 struct snd_sb_csp_info {
 struct snp_guest_request_ioctl {
 struct sock_fprog {
 struct sockaddr_atmpvc {
 struct sockaddr_atmsvc {
 struct sockaddr_ax25 {
 struct sockaddr_caif {
 struct sockaddr_can {
 struct sockaddr_nfc {
 struct sockaddr_nfc_llcp {
 struct sockaddr_qrtr {
 struct sockaddr_rose {
 struct stat64 {
 struct taskstats {
 struct tc_connmark {
 struct tc_ife {
 struct tc_pedit_sel {
 struct unimapdesc {
 struct usb_raw_ep_info {
 struct usb_raw_eps_info {
 struct usbdevfs_connectinfo {
 struct usbdevfs_urb {
 struct uvc_xu_control_query {
 struct uvesafb_task {
 struct vbg_ioctl_log {
 struct vduse_iotlb_entry {
 struct vduse_vq_info {
 struct vfio_device_info_cap_zpci_group {
 struct virtio_net_hash_config {
 struct virtio_net_rss_config {
 struct vlan_ioctl_args {
 struct xfrm_encap_tmpl {
 struct xfrm_selector {
 struct xfrm_user_acquire {
 struct xfrm_user_expire {
 struct xfrm_user_kmaddress {
 struct xfrm_user_offload {
 struct xfrm_user_polexpire {
 struct xfrm_user_report {
 struct xfrm_userpolicy_id {
 struct xfrm_userpolicy_info {
 struct xfrm_usersa_info {
 struct xfrm_userspi_info {
 struct xsdfec_ldpc_params {
 struct xsdfec_status {
 struct xsdfec_turbo {
 struct xt_bpf_info {
 struct xt_connmark_mtinfo1 {
 struct xt_connmark_tginfo1 {
 struct xt_conntrack_mtinfo2 {
 struct xt_conntrack_mtinfo3 {
 struct xt_entry_match {
 struct xt_entry_target {
 struct xt_error_target {
 struct xt_esp {
 struct xt_helper_info {
 struct xt_hmark_info {
 struct xt_ipcomp {
 struct xt_iprange_mtinfo {
 struct xt_mac_info {
 struct xt_mark_mtinfo1 {
 struct xt_owner_match_info {
 struct xt_realm_info {
 struct xt_secmark_target_info {
 struct xt_secmark_target_info_v1 {
 struct xt_set_info_match_v0 {
 struct xt_set_info_match_v3 {
 struct xt_set_info_target_v0 {
 struct xt_set_info_v0 {
 struct xt_time_info {
 struct xt_tproxy_target_info {
 struct xt_tproxy_target_info_v1 {
 struct xt_u32 {
 struct xt_u32_location_element {
 struct xt_u32_test {
 union __sifields {
 union ethtool_flow_union {

Re: Plan needed for switching m68k to 32-bit alignment

[Greg Ungerer]

On 26/10/24 09:42, Thorsten Glaser wrote:
> 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,

There is plenty of Linux on ColdFire, but all the m68k'isms apply the same.


> 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

Re: Plan needed for switching m68k to 32-bit alignment

[Arnd Bergmann]

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.

      Arnd

Re: Plan needed for switching m68k to 32-bit alignment

[Thorsten Glaser]

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.

bye,
//mirabilos
-- 
22:20⎜<asarch> The crazy that persists in his craziness becomes a master
22:21⎜<asarch> And the distance between the craziness and geniality is
only measured by the success 18:35⎜<asarch> "Psychotics are consistently
inconsistent. The essence of sanity is to be inconsistently inconsistent

Re: Plan needed for switching m68k to 32-bit alignment

[Thorsten Glaser]

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?

bye,
//mirabilos
-- 
>> Why don't you use JavaScript? I also don't like enabling JavaScript in
> Because I use lynx as browser.
+1
	-- Octavio Alvarez, me and ⡍⠁⠗⠊⠕ (Mario Lang) on debian-devel

Re: Plan needed for switching m68k to 32-bit alignment

[Greg Ungerer]

On 28/10/24 13:19, Thorsten Glaser wrote:
> 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?

No, there is a few ColdFire family members with MMU, specifically the version 4
core parts (547x, 548x, 5441x and 5445x). All supported by Linux, and popular
with some because they are significantly faster then the 68060. I regularly
(as in every mainline rc and kernel release) test on the 5475, and recently I
was sent a 54418 board and test on that now too.

To be fair though I build complete embedded systems and don't generally rely
on distros for a user space. So a flag day API change would not bother me at all.
That may well not be true for all ColdFire users 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?

Nothing special or different that I can think of. The struct alignment used
is the same as for standard m68k, so the problem is the same. The only user
space visible differences I can think of is the slight difference in layout
for the ptrace pt_regs struct. And those elements are probably problematic with
the mix of bit fields short/long at the end.

Regards
Greg

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]


On Mon, 28 Oct 2024, Thorsten Glaser wrote:

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

Do I misunderstand or disbelieve? Or have you forgotten what I wrote two 
days ago?

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.

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Fri, 2024-10-25 at 17:07 +0200, Andreas Schwab wrote:
> 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.

Thanks for explaining the background. However, it doesn't change the
fact that this is blocking a lot of software now, unfortunately.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Fri, 2024-10-25 at 23:38 +0200, Thorsten Glaser wrote:
> 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?

James Le Cuirot (chewi) has created a Gentoo/m68k chroot with 4-byte
alignment and most of the stuff just worked from what I remember.

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

Yes, see above.

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

I assume so. Chewi, can you answer that question?

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Sat, 2024-10-26 at 00:24 +0200, Andreas Schwab wrote:
> 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.

Chewi made it to work with a minimal patch in glibc:

> https://marc.info/?l=glibc-help&m=169303990426196&w=2

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Sat, 2024-10-26 at 18:31 +1100, Finn Thain wrote:
> > 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. 
> 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.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

Hi Geert,

On Sat, 2024-10-26 at 12:46 +0200, Geert Uytterhoeven wrote:
> On Fri, Oct 25, 2024 at 11:38 PM Thorsten Glaser <tg@debian.org> 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...

Those are easier to fix though than trying to get LLVM work with
16-bit alignment. The former will just require removing that check.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Sun, 2024-10-27 at 00:04 +0200, Thorsten Glaser wrote:
> > That seems to imply that someone requires that those packages are ported.
> 
> Yes, we do. Rust especially is killing the entire FOSS ecosystem.

Could we leave out politics out of this discussion, please?

> These all are conditio sine qua nōn when it comes to continuing
> Linux/m68k, as a whole.

Exactly.

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

Yep, that's exactly my experience as well while building with 32-bit alignment
just made it work.

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

Agreed.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Sun, 2024-10-27 at 13:49 +1100, Finn Thain wrote:
> 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

It's not just about Rust:

> 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

This is getting off-topic.

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

The "collaboration" currently means me doing 100% of the Debian/m68k work.

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

What ecosystem? Do you honestly care that any hobbyist cares about having
to reinstall their retro computers?

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

Again off-topic.

> > “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;
> };

We're dealing with today's software and not something that exists in 50 years.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Sun, 2024-10-27 at 03:08 +0000, Thorsten Glaser wrote:
> > 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.

Again, it isn't just about Rust. Virtually every relevant project requires
32-bit alignment these days, including CPython. I assume that CPython is
nothing that anyone here would call exotic or killing open-source, no?

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

Yup, m68k is the only port in Debian with these issues.

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

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Sun, 2024-10-27 at 14:47 +1100, Finn Thain wrote:
> 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.

There is hardly anyone to collaborate with. Plus, the problem is that 99%
the upstream projects will not carry any patches that unbreak their software
on m68k.

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

Sorry, but this a moot argument. Arguing with what could be in 50 years isn't
helpful here if it just intended to quench the discussion.

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

All this discussion doesn't help solve the real world problems with the m68k port.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Sun, 2024-10-27 at 17:16 +1100, 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 
> work. Perhaps a better solution would be language changes to allow a 
> struct definition to be qualified with an explicit data model.

This is a pure academic discussion and not leading anywhere.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

Hello Arnd,

On Sun, 2024-10-27 at 12:58 +0000, Arnd Bergmann wrote:
> On Fri, Oct 25, 2024, at 22:24, Andreas Schwab wrote:
> > 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.
> 
> I tried writing a small script that compiles each exported
> kernel header in order to get the debugging data for struct
> definitions. This is the list of the 236 structures that
> pahole reports being different with -malign-int. I probably
> missed a small number in header files that failed to build
> standalone, but this covers most.
> 
> I think it makes sense to go through these anyway and annotate
> them to document and enforce the alignment we actually want
> regardless of -malign-int, either by adding architecture
> specific __packed/__aligned attributes, or by adding explicit
> 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.

Thanks a lot! This is a very constructive contribution to the discussion.

I will create a page on the Debian (or Gentoo) Wiki to collect such information.

Adrian

> ---
>  struct _IOCTL_Command_struct {
>  struct _MGSL_PARAMS {
>  struct __fat_dirent {
>  struct __old_kernel_stat {
>  struct acrn_cstate_data {
>  struct acrn_pcidev {
>  struct atm_backend_ppp {
>  struct atm_qos {
>  struct atm_trafprm {
>  struct atmlec_config_msg {
>  struct atmlec_ioc {
>  struct atmlec_msg {
>  struct atmsvc_msg {
>  struct atmtcp_control {
>  struct ax25_ctl_struct {
>  struct ax25_route_opt_struct {
>  struct blk_user_trace_setup {
>  struct bpf_perf_event_data {
>  struct bpq_req {
>  struct br_mdb_entry {
>  struct br_mrp_in_role {
>  struct br_mrp_in_state {
>  struct br_mrp_instance {
>  struct br_mrp_start_in_test {
>  struct br_port_msg {
>  struct btrfs_ioctl_dev_replace_args {
>  struct btrfs_ioctl_dev_replace_start_par
>  struct cdrom_blk {
>  struct cdrom_generic_command {
>  struct cdrom_multisession {
>  struct cdrom_read_audio {
>  struct cdrom_subchnl {
>  struct cdrom_tocentry {
>  struct cycx_firmware {
>  struct cycx_fw_info {
>  struct dlm_lksb {
>  struct dlm_lock_result {
>  struct drm_etnaviv_pm_signal {
>  struct dvb_diseqc_slave_reply {
>  struct dvd_bca {
>  struct dvd_lu_send_title_key {
>  struct dvd_manufact {
>  struct dvd_physical {
>  struct ebt_arp_info {
>  struct ebt_arpreply_info {
>  struct ebt_mark_m_info {
>  struct ebt_nat_info {
>  struct ebt_stp_config_info {
>  struct ebt_stp_info {
>  struct edd {
>  struct efs_super {
>  struct eg_ctrl_info {
>  struct ethtool_ah_espip4_spec {
>  struct ethtool_ah_espip6_spec {
>  struct ethtool_rx_ntuple_flow_spec {
>  struct ethtool_tcpip4_spec {
>  struct ethtool_tcpip6_spec {
>  struct ethtool_usrip6_spec {
>  struct ethtool_wolinfo {
>  struct fat_boot_sector {
>  struct fb_cursor {
>  struct fb_fix_screeninfo {
>  struct fb_image {
>  struct floppy_drive_params {
>  struct floppy_fdc_state {
>  struct fs_quota_stat {
>  struct full_sockaddr_ax25 {
>  struct full_sockaddr_rose {
>  struct hdr_output_metadata {
>  struct hdsp_config_info {
>  struct hdsp_version {
>  struct hdspm_peak_rms {
>  struct hdspm_status {
>  struct hdspm_version {
>  struct he_ioctl_reg {
>  struct hiddev_devinfo {
>  struct hv_kvp_msg {
>  struct i2c_msg {
>  struct i2c_smbus_ioctl_data {
>  struct i2o_sw_xfer {
>  struct idmap_msg {
>  struct ieee_pfc {
>  struct ifla_vf_vlan_info {
>  struct in_ctrl_info {
>  struct inet_diag_hostcond {
>  struct ip6t_ah {
>  struct ip6t_frag {
>  struct ip6t_rt {
>  struct ip6t_srh1 {
>  struct ip_set_counter_match0 {
>  struct ip_vs_dest_entry {
>  struct ip_vs_dest_user {
>  struct ip_vs_get_dests {
>  struct ip_vs_service_entry {
>  struct ip_vs_service_user {
>  struct ipmi_addr {
>  struct ipmi_ipmb_direct_addr {
>  struct ipmi_ssif_msg {
>  struct ipt_ah {
>  struct ipt_clusterip_tgt_info {
>  struct j1939_filter {
>  struct k_message {
>  struct loop_info {
>  struct media_link_desc {
>  struct media_pad_desc {
>  struct mf6cctl {
>  struct mfcctl {
>  struct mif6ctl {
>  struct msgbuf {
>  struct msginfo {
>  struct msqid_ds {
>  struct mtd_info_user {
>  struct mtop {
>  struct nd_papr_pdsm_health {
>  struct nd_papr_pdsm_smart_inject {
>  struct nf_nat_range2 {
>  struct nfs_mount_data {
>  struct nr_route_struct {
>  struct opal_geometry {
>  struct ovs_action_push_mpls {
>  struct ovs_key_arp {
>  struct ovs_key_ct_tuple_ipv4 {
>  struct ovs_key_ct_tuple_ipv6 {
>  struct pci_endpoint_test_xfer_param {
>  struct pg_read_hdr {
>  struct pg_write_hdr {
>  struct plipconf {
>  struct pt_regs {
>  struct ptrace_syscall_info {
>  struct qedr_create_qp_uresp {
>  struct rds6_info_rdma_connection {
>  struct rds_info_rdma_connection {
>  struct rio_rdev_info {
>  struct rkisp1_cif_isp_afc_config {
>  struct rkisp1_cif_isp_dpf_config {
>  struct rkisp1_cif_isp_dpf_nll {
>  struct rkisp1_cif_isp_isp_meas_cfg {
>  struct rkisp1_cif_isp_isp_other_cfg {
>  struct rkisp1_cif_isp_sdg_config {
>  struct rkisp1_cif_isp_stat {
>  struct rkisp1_ext_params_afc_config {
>  struct rkisp1_ext_params_dpf_config {
>  struct rkisp1_ext_params_sdg_config {
>  struct rkisp1_params_cfg {
>  struct rkisp1_stat_buffer {
>  struct rose_facilities_struct {
>  struct rtc_wkalrm {
>  struct scc_calibrate {
>  struct scc_modem {
>  struct scom_access {
>  struct semid_ds {
>  struct serial_multiport_struct {
>  struct serial_struct {
>  struct sigcontext {
>  struct sioc_mif_req6 {
>  struct sioc_vif_req {
>  struct sisfb_info {
>  struct snd_dm_fm_note {
>  struct snd_emu10k1_fx8010_pcm_rec {
>  struct snd_sb_csp_info {
>  struct snp_guest_request_ioctl {
>  struct sock_fprog {
>  struct sockaddr_atmpvc {
>  struct sockaddr_atmsvc {
>  struct sockaddr_ax25 {
>  struct sockaddr_caif {
>  struct sockaddr_can {
>  struct sockaddr_nfc {
>  struct sockaddr_nfc_llcp {
>  struct sockaddr_qrtr {
>  struct sockaddr_rose {
>  struct stat64 {
>  struct taskstats {
>  struct tc_connmark {
>  struct tc_ife {
>  struct tc_pedit_sel {
>  struct unimapdesc {
>  struct usb_raw_ep_info {
>  struct usb_raw_eps_info {
>  struct usbdevfs_connectinfo {
>  struct usbdevfs_urb {
>  struct uvc_xu_control_query {
>  struct uvesafb_task {
>  struct vbg_ioctl_log {
>  struct vduse_iotlb_entry {
>  struct vduse_vq_info {
>  struct vfio_device_info_cap_zpci_group {
>  struct virtio_net_hash_config {
>  struct virtio_net_rss_config {
>  struct vlan_ioctl_args {
>  struct xfrm_encap_tmpl {
>  struct xfrm_selector {
>  struct xfrm_user_acquire {
>  struct xfrm_user_expire {
>  struct xfrm_user_kmaddress {
>  struct xfrm_user_offload {
>  struct xfrm_user_polexpire {
>  struct xfrm_user_report {
>  struct xfrm_userpolicy_id {
>  struct xfrm_userpolicy_info {
>  struct xfrm_usersa_info {
>  struct xfrm_userspi_info {
>  struct xsdfec_ldpc_params {
>  struct xsdfec_status {
>  struct xsdfec_turbo {
>  struct xt_bpf_info {
>  struct xt_connmark_mtinfo1 {
>  struct xt_connmark_tginfo1 {
>  struct xt_conntrack_mtinfo2 {
>  struct xt_conntrack_mtinfo3 {
>  struct xt_entry_match {
>  struct xt_entry_target {
>  struct xt_error_target {
>  struct xt_esp {
>  struct xt_helper_info {
>  struct xt_hmark_info {
>  struct xt_ipcomp {
>  struct xt_iprange_mtinfo {
>  struct xt_mac_info {
>  struct xt_mark_mtinfo1 {
>  struct xt_owner_match_info {
>  struct xt_realm_info {
>  struct xt_secmark_target_info {
>  struct xt_secmark_target_info_v1 {
>  struct xt_set_info_match_v0 {
>  struct xt_set_info_match_v3 {
>  struct xt_set_info_target_v0 {
>  struct xt_set_info_v0 {
>  struct xt_time_info {
>  struct xt_tproxy_target_info {
>  struct xt_tproxy_target_info_v1 {
>  struct xt_u32 {
>  struct xt_u32_location_element {
>  struct xt_u32_test {
>  union __sifields {
>  union ethtool_flow_union {

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

Hi Arnd,

On Sun, 2024-10-27 at 13:15 +0000, Arnd Bergmann wrote:
> 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.

Another useful data point. This is the kind of discussion I had hoped for!

Thanks a lot!

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Mon, 2024-10-28 at 04:07 +0100, Thorsten Glaser wrote:
> 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).

Yep, that's exactly the problem. Plus, the maintainers of 99% of the upstream
projects don't care about the alignment peculiarities of the Linux/m68k port.

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

Agreed 100%.

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

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.

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

Currently, Gentoo supports i386 out of that list.

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

Did you see how Chewi implemented 32-bit alignment? He actually didn't
use -malign-int but directly patched GCC itself, see:

> https://marc.info/?l=glibc-help&m=169303990426196&w=2

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Mon, 2024-10-28 at 15:51 +1100, Finn Thain wrote:
> 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).

As I said before, it's about (transitive) build dependencies and the fact
that more and more packages are being rewritten in Rust.

Here is the current top of the list of packages that won't build on m68k
because of the 2-byte alignment issue:

   2814 cargo:m68k
    900 ghc:m68k
    261 gccgo-14:m68k
    241 libqt5core5a:m68k
    181 architecture-is-64-bit:m68k
    117 libglib2.0-0:m68k
     81 libcompiler-libs-ocaml-dev-0a396:m68k
     81 golang-go:m68k
     71 wx3.2-headers:m68k
     57 qt6-base-dev:m68k
     57 python3:m68k
     46 libamd2:m68k

Are you going to fix these for me?

> > For Debian, we have superh and i386, out of these.
> 
> Is your concern merely for Debian's package archive stats?

It's not about stats, it's about reverse dependencies.

And, to be honest, I'm started to get tired of this discussion. If there is not
going to be an agreement here, I will either drop the m68k port from Debian or
use the brute-force method with Chewi's patch.

I don't have the energy anymore to justify myself regarding this anymore.

> What interests me is portability and code reuse in general. That is the 
> basis on which I would send alignment patches to upstream projects.

Upstream projects do not take patches which fix code on m68k. They don't care.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

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.

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

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.

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

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.

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]


On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:

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

And they did so without needing a new ABI...

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:

> On Mon, 2024-10-28 at 15:51 +1100, Finn Thain wrote:
> 
> > 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).
> 
> As I said before, it's about (transitive) build dependencies and the 
> fact that more and more packages are being rewritten in Rust.
> 
> Here is the current top of the list of packages that won't build on m68k 
> because of the 2-byte alignment issue:
> 
>    2814 cargo:m68k
>     900 ghc:m68k
>     261 gccgo-14:m68k
>     241 libqt5core5a:m68k
>     181 architecture-is-64-bit:m68k
>     117 libglib2.0-0:m68k
>      81 libcompiler-libs-ocaml-dev-0a396:m68k
>      81 golang-go:m68k
>      71 wx3.2-headers:m68k
>      57 qt6-base-dev:m68k
>      57 python3:m68k
>      46 libamd2:m68k
> 
> Are you going to fix these for me?
> 

Are you the only user?

Seriously though, thanks for providing data. Now, if you would link to the 
upstream refusals for CPython and golang, I'll do what I can to help.

Re: Plan needed for switching m68k to 32-bit alignment

[Michael Schmitz]

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.

Cheers,

     Michael

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Mon, 2024-10-28 at 19:29 +1100, Finn Thain wrote:
> 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.

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?

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

Of course my opinion counts here because I am doing the majority of the work
on Debian m68k these days.

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

Again, this has been tried in the past and I'm tired of discussing this.

This kind of discussion doesn't really help resolving this problem.

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

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.

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

My opinion is that people expect 32-bit targets to not dissolve in thin air
in 2038. The fact that i386 was not touch is simply because of the huge
library of pre-compiled software for the platform which doesn't exist in
that form on m68k. So that's not an argument to switch the natural alignment.

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

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.

All I'm getting is "wise" advise on the quality of "Have you tried turning it
off and on again?".

Endlessly frustrated,

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

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.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Mon, 2024-10-28 at 19:44 +1100, Finn Thain wrote:
> On Mon, 28 Oct 2024, John Paul Adrian Glaubitz wrote:
> 
> > > 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.
> > 
> 
> And they did so without needing a new ABI...

Because on i386, the original ABI designers didn't make the mistake to enforce
an unnatural alignment.

Honestly, what exactly do you expect to achieve with messages like this?

If you want me to just drop the port, then just say it.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Mon, 2024-10-28 at 19:49 +1100, Finn Thain wrote:
> > Here is the current top of the list of packages that won't build on m68k 
> > because of the 2-byte alignment issue:
> > 
> >    2814 cargo:m68k
> >     900 ghc:m68k
> >     261 gccgo-14:m68k
> >     241 libqt5core5a:m68k
> >     181 architecture-is-64-bit:m68k
> >     117 libglib2.0-0:m68k
> >      81 libcompiler-libs-ocaml-dev-0a396:m68k
> >      81 golang-go:m68k
> >      71 wx3.2-headers:m68k
> >      57 qt6-base-dev:m68k
> >      57 python3:m68k
> >      46 libamd2:m68k
> > 
> > Are you going to fix these for me?
> > 
> 
> Are you the only user?

I am the one who does all the work on Debian/m68k.

> Seriously though, thanks for providing data. Now, if you would link to the 
> upstream refusals for CPython and golang, I'll do what I can to help.

I honestly don't have to justify myself towards you. I will use the Christmas
holidays to make a decision. I will either drop the m68k port from Debian or
just perform a forced switch.

I don't care anymore what you're posting here. You're just wasting my time.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Tue, 2024-10-29 at 07:57 +1300, Michael Schmitz wrote:
> 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).

Should extremely RAM-constrained systems be the reference target for m68k?

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

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Tue, 2024-10-29 at 14:39 +1100, Finn Thain wrote:
> 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...

Yes, who doesn't know the cloud instances with 64 MB RAM. Those are today's standard.

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

You can easily upgrade Amigas to 256 MB or more these days. The aftermarket
provides a lot of affordable upgrades these days.

> I don't mind if Gentoo ships a separate profile for (downstream) ABI 
> experimentation, leaving the default m68k profile on the standard ABI.

The Gentoo developers will be glad to hear that you don't mind. Do you think
they need a written permission from you?

> 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

That dependency chain comes from upstream, not from Debian.

> 2) among all developers working on non-commercial architectures, to 
>    improve the GCC Rust frontend

GCC Rust uses parts of the upstream Rust code, so you can expect the same
problems there as well.

> 3) among all 680x0 developers interested in the NetBSD ABI

The alignment issue affects NetBSD as well.

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

Software will run faster with 32-bit alignment, not slower.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[Michael Schmitz]

Adrian,

On 14/11/24 01:54, John Paul Adrian Glaubitz wrote:
> On Tue, 2024-10-29 at 07:57 +1300, Michael Schmitz wrote:
>> 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).
> Should extremely RAM-constrained systems be the reference target for m68k?

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

Cheers,

     Michael

>
> Adrian
>

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

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.

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

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.

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

Again, the problem is not Debian-specific. Heck, it's not even Linux-specific.

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

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.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[Stan Johnson]

On 11/13/24 12:55 PM, John Paul Adrian Glaubitz wrote:
> 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.
> 
>> 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.


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.


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


> 
> Again, the problem is not Debian-specific. Heck, it's not even Linux-specific.
> 
>>>> 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).
> 
> 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.
> 
> Adrian
> 

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Wed, 2024-11-13 at 20:55 +0100, John Paul Adrian Glaubitz wrote:
> > 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.

If your concern is that you won't be able to build a small userspace anymore,
then you should keep in mind that you will always be able to do that with the
help of Buildroot or Toybox.

FWIW, the suggestion to update the kernel ABI came from Geert, not from me.

Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[John Paul Adrian Glaubitz]

On Wed, 2024-11-13 at 13:48 -0700, Stan Johnson wrote:
> > 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).

If you really do not want to use systemd and need something small, you can
just build yourself a chroot using Buildroot or Toybox.

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

systemctl disable foo.service is too hard?

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

Old systems don't need user management or networking?

FWIW, these components can be turned off if you insist using a separate package
for each and every standard service that's part of the standard Linux userland.

You are not forced to use systemd components.

> Systemd even complains if I manually edit /etc/fstab.

Which is a good thing. SysVInit systems would just silently fail when you added
an entry to /etc/fstab which didn't work properly so that you could end up with
something not being mounted where it should be or vice versa.

Ignoring such failures provokes data loss. That's *not* a good thing.

> 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 using systemd on my Amiga and any other embedded system I have and it works.

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

You mean "professional" distributions like Devuan?

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

First of all, you can still and will always be able to build yourself a tiny
chroot using Buildroot or Toybox. And, secondly, what's the point of running
the latest and greatest kernel on a system which can't make use of any modern
kernel features anyway?


Adrian

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

Re: Plan needed for switching m68k to 32-bit alignment

[Thorsten Glaser]

(please keep my debian.org address in the distribution list,
not the mirbsd one, as it has better chance to interact with
other mail providers out there for this… except Googlemail,
which, of course, is no proper mail provider and actively
disrecommended because it fails to collaborate for FOSS work)

On Wed, 13 Nov 2024, John Paul Adrian Glaubitz wrote:

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

Indeed.

We should consider something with 256 MiB RAM the “default”
(which also matches the usual “smallest VM”; there are VMs
with just 128 MiB RAM, but even just running apt-get update
can stretch them to swap) and, perhaps, try to keep systems
with 64 MiB working, perhaps with custom kernels. But 256 MiB
is plenty for a normal OSS stack (i.e. no dbus/systemd, proper
classical init), without X11 anyway, but perhaps even with it.

>SysVInit uses a huge set of bash scripts where every action involves spawning

sh scripts, mksh’s /bin/lksh gives a 3× speedup, compared to
GNU bash, here, probably even more, as it’s statically linked.

[ low memory ]
>Again, the problem is not Debian-specific. Heck, it's not even Linux-specific.

ACK.

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

I don’t buy this.

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

① not for the userspace ABI to change, anyway; that can be decoupled
  is the point here

bye,
//mirabilos
-- 
11:56⎜«liwakura:#!/bin/mksh» also, i wanted to add mksh to my own distro │
i was disappointed that there is no makefile │ but somehow the Build.sh is
the least painful built system i've ever seen │ honours CC, {CPP,C,LD}FLAGS
properly │ looks cleary like done by someone who knows what they are doing

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

On Wed, 13 Nov 2024, John Paul Adrian Glaubitz wrote:

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

I'm interested in what people have to say. I'm not interested in who says 
it. Hence, your concept of "everyone else" is irrelevant to me.

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

On Wed, 13 Nov 2024, John Paul Adrian Glaubitz wrote:

> > Then don't leave it to chance.
> 
> What is supposed to mean? Are you implying that I never tried to address 
> this?
> 

Obviously, it means I'm not interested in your estimation of the chances 
of rejection. But you're still trying to twist my words into a slur. How 
tiresome.

Again, I'd like to see an actual example of upstream developers rejecting 
patches that improve portability of data structures to m68k (and to 16-bit 
systems).

> Did you have a try at fixing any of these?
> 

Would you like me to stop fixing bugs that users actually report, in order 
to fix bugs that only distros complain about?

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

Again, the real problem faced by Debian/m68k and Gentoo/m68k is a shortage 
of manpower. This is not a new problem.

An ABI change will not fix this problem though I do conceed that a 
different ABI could improve the distro's package archive statistics, for 
all that's worth.

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

No, you're not really interested in progress. There's nothing particularly 
novel about running bloated packages in fast emulators.

And yet, I do agree that actual progress would require a new ABI, and 
you've even heard me say so before though you appear to have forgotten. 
https://lists.debian.org/debian-68k/2023/08/msg00023.html

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

If LLVM developers say that their software is inappropriate for an ABI 
that does not have 4-byte minimal alignment (citation needed) then I'd 
accept their judgement on that.

And when I want to run LLVM and its reverse deps on my m68k systems, I'll 
run them under NetBSD/mac68k.

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

Then don't work on it.

My Gentoo/x86 laptop installation is now twenty one years old, is 
up-to-date, and has never had LLVM installed on it. Nor do I miss it.

nippy portage # wc -l /var/log/emerge.log 
409801 /var/log/emerge.log
nippy portage # head /var/log/emerge.log
1063261888: Started emerge on: Sep 11, 2003 06:31:27
1063261888:  *** emerge  >=sys-apps/portage-2.0.25
1063261888:  >>> emerge (1 of 1) sys-apps/portage-2.0.49-r4 to /
1063261888:  === (1 of 1) Cleaning (/usr/portage/sys-apps/portage/portage-2.0.49-r4.ebuild)
1063261888:  === (1 of 1) Compiling/Merging (/usr/portage/sys-apps/portage/portage-2.0.49-r4.ebuild)
1063261911:  === (1 of 1) Post-Build Cleaning (/usr/portage/sys-apps/portage/portage-2.0.49-r4.ebuild)
1063261911:  ::: completed emerge (1 of 1) sys-apps/portage-2.0.49-r4 to /
1063261911:  *** Finished. Cleaning up...
1063261911:  *** exiting successfully.
1063261911:  *** terminating.

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

I'm keen to see where the python requirements were changed. I wasn't able 
to find that document on python.org.

If you don't want to port python 3.13 to m68k that's okay with me. And if 
you're unwilling to port any packages to any quirky architectures, that's 
okay with me too.

But if you still claim that upstream developers require certain alignment 
rules, then you still have to provide evidence for that. Despite all of my 
requests for that evidence, none has been offered.

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

On Wed, 13 Nov 2024, John Paul Adrian Glaubitz wrote:

> 
> > 3) among all 680x0 developers interested in the NetBSD ABI
> 
> The alignment issue affects NetBSD as well.
> 

My experiments showed that my NetBSD/mac68k system aligns int struct 
members like my i686 system does.

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]


On Wed, 13 Nov 2024, Thorsten Glaser wrote:

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

Yes, upstream developers can be expected accept patches that make explicit 
the alignment of struct members. That's what I've been saying for years. 

Luckily, that doesn't require a new ABI. It does require volunteers who 
are willing to write and submit patches for those packages that matter to 
users.

And that is the real problem: the manpower shortage. The only solution I 
proposed for that problem was better collaboration and better allocation 
of resources. But his straight-forward request for assistance was an 
excellent idea of Adrian's:
https://lists.debian.org/debian-68k/2024/11/msg00007.html

Re: Plan needed for switching m68k to 32-bit alignment

[Geert Uytterhoeven]

On Sun, Oct 27, 2024 at 7:16 AM Finn Thain <fthain@linux-m68k.org> 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?

Gr{oetje,eeting}s,

                        Geert

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

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

Re: Plan needed for switching m68k to 32-bit alignment

[Stan Johnson]

On 11/13/24 2:01 PM, John Paul Adrian Glaubitz wrote:
>>>>>> 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.
> 
> 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).
But if I'm using sysvinit scripts, I can boot a rescue CD, or Gentoo, or
whatever else I might have installed, mount the relevant root
filesystem, then disable the sysvinit script (delete it or change the
leading "S" to "s") or use a text editor to fix it.

> 
>> 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.
> 
> Old systems don't need user management or networking?

Yes, of course they do, but some users don't expect or want their init
system to perform those functions.

> 
> FWIW, these components can be turned off if you insist using a separate package
> for each and every standard service that's part of the standard Linux userland.
> 
> You are not forced to use systemd components.
> 
>> Systemd even complains if I manually edit /etc/fstab.
> 
> Which is a good thing. SysVInit systems would just silently fail when you added
> an entry to /etc/fstab which didn't work properly so that you could end up with
> something not being mounted where it should be or vice versa.

I'd probably see an error message in the log files or at boot time if I
added an incorrect entry to /etc/fstab. Some users don't want their init
system to be a nanny, especially on a slow system.

> 
> Ignoring such failures provokes data loss. That's *not* a good thing.

True enough. No one is suggesting ignoring misconfigurations; I'm just
suggesting that systemd isn't the right place to provide nanny services.

> 
>> 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 using systemd on my Amiga and any other embedded system I have and it works.
> 
>> 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.
> 
> You mean "professional" distributions like Devuan?

Devuan is great, even if it's not as "professional" as Debian. If I
required a professional distribution, then I would pay for professional
support. As it is, Debian is probably converting more users to Devuan
than anyone else. I had to install Devuan on several Apple x86_64
systems because Debian keeps breaking X11 support by making systemd a
dependency (even if it's a temporary mistake, and I know you aren't
involved with x86_64). This is a hobby for many of us, and we don't need
the drama. Besides Devuan, Gentoo is also very good. So is Void, though
they recently removed support for everything except i386 and x86_64. And
of course there's always NetBSD, though it has some issues booting on
powerpc.

Re: Plan needed for switching m68k to 32-bit alignment

[Geert Uytterhoeven]

On Thu, Nov 14, 2024 at 7:07 PM Stan Johnson <userm57@yahoo.com> wrote:
> On 11/13/24 2:01 PM, John Paul Adrian Glaubitz wrote:
> >>>>>> 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.
> >
> > 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).

That's also my experience: when it fails, in 50% of the cases the
system doesn't boot sufficiently far to use systemctl.

But all of that is irrelevant for an alignment discussion...

Gr{oetje,eeting}s,

                        Geert

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

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

Re: Plan needed for switching m68k to 32-bit alignment

[Geert Uytterhoeven]

Hi Adrian,

On Wed, Nov 13, 2024 at 8:55 PM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> 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

No, we're not. Kernel images don't grow ca. 25 KiB per kernel release,
and web browsers still run fine in 16 MiB ;-)

> like systemd or Rust-compiled software actually use less memory, not more.

Last May, systemd in Debian/sid required me to enable CONFIG_CGROUPS and
CONFIG_DEBUG_FS. Last weekend, I had to add CONFIG_USER_NS.
Yes, that's a small drop in the kernel sea, but all drops count.

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

How many m68k systems actually have 256 MiB of RAM?

Gr{oetje,eeting}s,

                        Geert

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

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

Re: Plan needed for switching m68k to 32-bit alignment

[Geert Uytterhoeven]

Hi Thorsten,

On Fri, Oct 25, 2024 at 11:38 PM Thorsten Glaser <tg@debian.org> wrote:
> 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?

As pointed out by Arnd, there are.

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

Gr{oetje,eeting}s,

                        Geert

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

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

Re: Plan needed for switching m68k to 32-bit alignment

[Thorsten Glaser]

On Thu, 14 Nov 2024, Geert Uytterhoeven wrote:

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

I’d say yes. Probably the i386 psABI is so old that it is very
weird and nōn-standard in some ways.

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

Hmm hmm.

>If we decide to change alignment, I'd rather change all types to
>natural alignment, to avoid future nasty surprises.

That was my thought; the question is whether toolchain maintainers
(upstreams) will be amenable and helpful.

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

amd64’s long double is an SSE2 data type whereas i386’s is actually
an 80387 data type (same as m68k’s really), so they aren’t comparable.

I’d probably suggest aligning long double to 8 octets, like double.

It’s not a common data type (and probably one best avoided) anyway.

bye,
//mirabilos
-- 
(gnutls can also be used, but if you are compiling lynx for your own use,
there is no reason to consider using that package)
	-- Thomas E. Dickey on the Lynx mailing list, about OpenSSL

Re: Plan needed for switching m68k to 32-bit alignment

[James Le Cuirot]

On Thu, 14 Nov 2024, at 22:13, Thorsten Glaser wrote:
> On Thu, 14 Nov 2024, Geert Uytterhoeven wrote:
>
>>If we decide to change alignment, I'd rather change all types to
>>natural alignment, to avoid future nasty surprises.
>
> That was my thought; the question is whether toolchain maintainers
> (upstreams) will be amenable and helpful.

It may help that LLVM/Clang does not currently support -malign-int at all.

Re: Plan needed for switching m68k to 32-bit alignment

[Finn Thain]

[-- Attachment #1: Type: text/plain, Size: 1019 bytes --]


On Thu, 14 Nov 2024, Geert Uytterhoeven wrote:

> On Sun, Oct 27, 2024 at 7:16 AM Finn Thain <fthain@linux-m68k.org> 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
> 
> ???

My i686 compiler agrees with your compiler. Whereas on Linux/m68k, 
__alignof__(struct baa) == 2. 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...

Re: Plan needed for switching m68k to 32-bit alignment

[Thorsten Glaser]

On Fri, 15 Nov 2024, Finn Thain wrote:

>On NetBSD/m68k I get,
>
>sizeof(struct baa) == 16
>__alignof__(long long) == 8
>__alignof__(struct baa) == 8

That makes sense.

>> Isn't the alignment of a struct the largest alignment of any of its members?
>
>Sometimes...

I think I have a rough idea why i386 is weird here.
It famously can misalign, and it probably loads the
members as two separate dwords, being a 32-bit CPU,
and does not offer atomics for it, and so the initial
psABI decided to do that. Or something. If it helps,
it’s just as weird on MirBSD/i386, where this was no
deliberate decision.


tg@fish:~ $ ./a.out
int     s=4     a=4
llong   s=8     a=8
baa     s=12    a=4
baa.a   s=4     a=4     o=0
baa.b   s=8     a=4     o=4

vs.

(pbuild22802-bookworm/i386)root@cafe:/tmp# ./a.out
int     s=4     a=4
llong   s=8     a=8
baa     s=12    a=4
baa.a   s=4     a=4     o=0
baa.b   s=8     a=4     o=4

vs. (Linux/amd64)

tg@x61p:~ $ ./a.out
int     s=4     a=4
llong   s=8     a=8
baa     s=16    a=8
baa.a   s=4     a=4     o=0
baa.b   s=8     a=8     o=8


But we certainly need to avoid following the other special
case and rather design the post-switch ABI so that it is
as easily handled as any other new ILP32 ABI for another
architecture, when we change it already anyway.

Two questions:

ⓐ if Clang+LLVM doesn’t know -malign-int anyway, and if its
  capability to output code for m68k is experimental to
  nōnexistent right now, do we even need to take it into
  account? Perhaps changing it to always use the new one is good.

ⓑ what does NetBSD do to get the result (considering that
  -malign-int supposedly only changes int to 4), patch GCC?

Of particular interest are a couple definitions in…
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/m68k/netbsd-elf.h;h=3d2043bbe7087ac58f0d2c4336734f7a37bba02f;hb=HEAD#l269
… versus the arch defaults in:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/m68k/m68k.h;h=0d57199714361ff9ed7f92ef28e36f71aee326b3;hb=HEAD#l290

With a bit of luck this means that raising BIGGEST_ALIGNMENT
is sufficient to give us 8-octet-aligned doubles and long doubles.
Then we “just” need to raise the other definitions that indicate
16-bit alignment to 32. (TARGET_SHORT is -mshort is I16LP32 and
so doesn’t need consideration for Linux/m68k.)

I’m not sure anything needs to have 128-bit alignment that won’t
explicitly specify that via attributes.

bye,
//mirabilos
-- 
Yay for having to rewrite other people's Bash scripts because bash
suddenly stopped supporting the bash extensions they make use of
	-- Tonnerre Lombard in #nosec

Re: Plan needed for switching m68k to 32-bit alignment

[Thorsten Glaser]

Forgot…

>tg@fish:~ $ ./a.out

struct baa {
	int a;
	long long b;
};

#include <stddef.h>
#include <stdio.h>

int main(void) {
	struct baa stct;

#define t(w,s) printf("%s\ts=%u\ta=%u\n", #w, \
	    (unsigned)sizeof(s), (unsigned)__alignof__(s))
#define o(w,m) printf("%s\ts=%u\ta=%u\to=%u\n", #w, \
	    (unsigned)sizeof(stct.m), (unsigned)__alignof__(stct.m), \
	    (unsigned)offsetof(struct baa, m))
	t(int, int);
	t(llong, long long);
	t(baa, struct baa);
	o(baa.a, a);
	o(baa.b, b);
	return (0);
}

bye,
//mirabilos
-- 
[16:04:33] bkix: "veni vidi violini"
[16:04:45] bkix: "ich kam, sah und vergeigte"...