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.
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.
I am bringing the later because I fixed some recent m68k build issues [1], that
seems to be from gcc changes over the years (as hinted by Andreas Schwab) where
compiler changed some internal defined flags and it was not reflected on glibc
(for a short, it seems that -mcpu=680X0 does not already define __mc68020__).
The build fix is straightforward, but it raised question whether something
else is not broken and has not been caught yet.
I had been aware of that issue for a while, but I wasn't able to figure it out
in a few minutes, and I never got around to looking deeper. Sorry for not
reporting it sooner.
Waldemar Brodkorb has posted his results on running glibc 2.38 on qemu and
it shows a lot of regression:
949 FAIL
3344 PASS
99 UNSUPPORTED
16 XFAIL
2 XPASS
I guess the math failures are from the extra rounding and exception testing, which
requires a fully compliant IEEE 754 fp unit (which I guess m68k does not provide).
The last m68k testsuite report where from 2.26 release [1] running under ARAnyM,
which shows the port is a better shape.
The FP failures are 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?
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.
