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

[Thorsten Glaser <tg@debian.org>]

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