From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from outpost1.zedat.fu-berlin.de (outpost1.zedat.fu-berlin.de [130.133.4.66]) by sourceware.org (Postfix) with ESMTPS id C9F5B3858C54 for ; Mon, 28 Aug 2023 12:50:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C9F5B3858C54 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=physik.fu-berlin.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=zedat.fu-berlin.de Received: from inpost2.zedat.fu-berlin.de ([130.133.4.69]) by outpost.zedat.fu-berlin.de (Exim 4.95) with esmtps (TLS1.3) tls TLS_AES_256_GCM_SHA384 (envelope-from ) id 1qabhl-000VGm-Ad; Mon, 28 Aug 2023 14:50:53 +0200 Received: from p57bd925a.dip0.t-ipconnect.de ([87.189.146.90] helo=[192.168.178.81]) by inpost2.zedat.fu-berlin.de (Exim 4.95) with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (envelope-from ) id 1qabhk-002gaU-Se; Mon, 28 Aug 2023 14:50:53 +0200 Message-ID: <87134fda9b761e3f81588d440242b9a4e986ddbf.camel@physik.fu-berlin.de> Subject: Re: Tuple and changes for m68k with -malign-int From: John Paul Adrian Glaubitz To: Adhemerval Zanella Netto , Finn Thain Cc: James Le Cuirot , libc-help@sourceware.org, debian-68k , linux-m68k Date: Mon, 28 Aug 2023 14:50:52 +0200 In-Reply-To: References: <10cbcb8a65639f88e7eeb503fd02df172bc46a07.camel@physik.fu-berlin.de> <80a52487-3105-ed5b-a1eb-ec1a0689ef21@linux-m68k.org> <4b4fe9c56dfdb8ec74150413cfc211d70243eb7e.camel@physik.fu-berlin.de> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.48.4 MIME-Version: 1.0 X-Original-Sender: glaubitz@physik.fu-berlin.de X-Originating-IP: 87.189.146.90 X-ZEDAT-Hint: PO X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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 diffe= rent > loader and the question: will it be interoperable with current m68k ABI i= n the=20 > 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 (suc= h as=20 > pthread_mutex_t and alike) have the same layout and alignment, add some s= upport > to ldconfig to differentiated between DSO with different ABIs (either thr= ough=20 > e_flags as ARM, PT_GNU_PROPERTY used by aarch64 or x86_64, or something e= lse), > bump the required minimum kernel (for 64 bit time_t support), and check c= urrent > 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=3D680X0 does not already define __mc680= 20__). > The build fix is straightforward, but it raised question whether somethin= g > else is not broken and has not been caught yet. >=20 > Waldemar Brodkorb has posted his results on running glibc 2.38 on qemu an= d > it shows a lot of regression: >=20 > 949 FAIL > 3344 PASS > 99 UNSUPPORTED > 16 XFAIL > 2 XPASS >=20 > I guess the math failures are from the extra rounding and exception testi= ng, which=20 > 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 em= ulation 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 ARAn= yM. > I also noted that gcc on mc68060 changed the __DEC_EVAL_METHOD__ to 2, wh= ich makes=20 > 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. >=20 > All of this issues and potentially work required for a new ABI makes me w= onder > if is really worth to keep *2* distinct ABIs for m68k. Yes, m68k can fol= low 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 wi= ll 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 th= e old ABI with 16-bit alignment. After all, we had to change the ABI for TLS supp= ort as well, didn't we? Adrian --=20 .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913