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

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

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.

> It would require take care that some possible shared data structures (such as 
> pthread_mutex_t and alike) have the same layout and alignment, add some support
> to ldconfig to differentiated between DSO with different ABIs (either through 
> e_flags as ARM, PT_GNU_PROPERTY used by aarch64 or x86_64, or something else),
> bump the required minimum kernel (for 64 bit time_t support), and check current
> status of the port.

Understood.

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

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

Adrian

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