Re: Tuple and changes for m68k with -malign-int

[John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>]

On Mon, 2023-08-28 at 14:29 +0100, James Le Cuirot wrote:
> On Mon, 2023-08-28 at 14:50 +0200, John Paul Adrian Glaubitz wrote:
> > Hi Adhemerval!
> > 
> > On Mon, 2023-08-28 at 09:44 -0300, Adhemerval Zanella Netto wrote:
> > > If the idea is really to endeavor on a new ABI for m68k, it means a different
> > > loader and the question: will it be interoperable with current m68k ABI in the 
> > > sense that i686 is interoperable with x86_64? It would allow to keep old binaries
> > > running, similar to what old ABI did for 32 to 64 bits transition.
> > 
> > OK.
> 
> To that, I would add: what old binaries? Linux on m68k is very obscure these
> days, with Gentoo, Debian, and NixOS being the only major distributions still
> supporting it. As the Gentoo m68k maintainer, I would not expect users to be
> pulling binaries from elsewhere, and I imagine Adrian would say the same.
> Where would you even get them from? I thought there might be a handful on
> Aminet, but I cannot even find any there.

Fully agreed.

> Upgrading an existing system might be awkward, but time_t alone will probably
> warrant a reinstall. Having said that, I just tried a somewhat unscientific
> experiment of running a bunch of random binaries from my 32-bit aligned system
> on my 16-bit aligned one and nothing broke. I then tried the reverse and saw
> stash smashing detection kicking in on anything more complex than ls.

Thanks so much for performing such tests. This is really appreciated and provides
valuable information that's very helpful for the transition process.

> > 
> > most likely the result of the limitations of the FPU emulation
> > in QEMU for m68k. ARAnyM is known to have much better FPU emulation support than
> > QEMU, so if you want to have more accurate results, you should test on ARAnyM.
> 
> This is fairly typical of the math-related test failures I have seen from
> other projects. I hadn't realised that QEMU's FPU emulation was lacking and
> had just chalked it up to m68k's FP hardware having different capabilities.
> Either way, I have never noticed any issues here when using software in
> practise. Not that I've done any heavy number crunching on m68k, but who
> would?

There have always been FPU-relevant issues on both QEMU and Aranym although it's
better on Aranym than on QEMU. This is a well known issue.

> > > I also noted that gcc on mc68060 changed the __DEC_EVAL_METHOD__ to 2, which makes 
> > > glibc tests to fail to build (since it assumes __DEC_EVAL_METHOD__ equal 0). This
> > > again raised questions on how the math library would behave depending of the target
> > > chip.
> > > 
> > > All of this issues and potentially work required for a new ABI makes me wonder
> > > if is really worth to keep *2* distinct ABIs for m68k.  Yes, m68k can follow the
> > > MIPS mess and have 28 different ABIs that fails to be fully interoperable; but
> > > I think that if you really want to on this 'gnu32' journey, I think it will be
> > > better to just deprecate the m68k current ABI, remove it from glibc; and move
> > > everything to new ABI.
> > 
> > I actually wouldn't have a problem with that. I don't plan on supporting the old
> > ABI with 16-bit alignment. After all, we had to change the ABI for TLS support
> > as well, didn't we?
> 
> I don't want to force anyone here, but I'd also be fine with that. The only
> downside, apart from compatibility, appears to be slightly increased memory
> usage, and you're not exactly going to run modern Linux with 8MB RAM anyway.

Agreed. And I finally want to be able to use Rust and LLVM on m68k ;-).

Adrian

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