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

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