From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by sourceware.org (Postfix) with ESMTPS id CDFEA3858D33 for ; Mon, 28 Aug 2023 13:29:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CDFEA3858D33 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=aura-online.co.uk Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=aura-online.co.uk Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E341B5C013F; Mon, 28 Aug 2023 09:29:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Mon, 28 Aug 2023 09:29:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= aura-online.co.uk; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm3; t=1693229387; x=1693315787; bh=Hu N58FoUyDKECq9gMjHjBiomI+0+zuD12tWG9HWhkKs=; b=kDsrhZIkIOcOU5jVC4 G0P3HfRU+K5spO/Itx+5AF9lSb1Atwv/FsSdhZxdRyefb05H5xauK/AqCq6SvMor TnHlgAkeWdOm6qVb73a3rCrugoFE4TMugSaLQtOwuIrJrFMlMWo26oBYRhF/JU+F 4b+lQeJQJSa/I4jh25qfkdwfeKUOQdLVXqqnHrESWGIsWkPXfzqhn3mxlCSEUWIY utQ1e/nb7XMHeiTwGquvuGShKzPFmWVTBVuQb0Z/VYVIGr4VWH6+Pr8Ha9zoek/a nhLP+IyEBqKNK3RZDWPw2U/UqQR26GyioOMaj+Ti89OjheA992PePYqviP0u1zFt Hv0Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1693229387; x=1693315787; bh=HuN58FoUyDKECq9gMjHjBiomI+0+zuD12tW G9HWhkKs=; b=FHjW2/kc6XcM/GnoSHQU9+VSimHAZtRCrzG27xi72Zxss0D5QuR 0YEjPv55QDwMnY5xKS/sy0oJ8/53UEXMeB1g1q2qWoFYLYpoYnwxiBBJNTJV/FUT Ye9L12N6TjG4WfusWkSXYrpRbM/SkBqNa7oSiobxz2+AHIjaqiPozX2xviOUVDK1 lki2XxtfniMl39kiHdtZ9Jvr8Muj92Nuxa0pfN50LYyUWmArzkvrqHxDHFp58lWx 2l1RBsx9oGerwD3eRtMiRrf3xDM3LDMvUfka2Cu1Z/7N8OuIGmniZsRz5a9HZXuW cGwz6HjtuGDtnm3wxWWnFbZHhxslz1TWTWA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudefgedgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkffuhffvveffjghftgfgfgggsehtqhertddtreejnecuhfhrohhmpeflrghm vghsucfnvgcuvehuihhrohhtuceotghhvgifihesrghurhgrqdhonhhlihhnvgdrtghord hukheqnecuggftrfgrthhtvghrnhepjeeifeevudeltdekiedvhfdtffeufeeiteefieeh tdfgfeelfeegffefleevveetnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpe hmrghilhhfrhhomheptghhvgifihesrghurhgrqdhonhhlihhnvgdrtghordhukh X-ME-Proxy: Feedback-ID: i51cd41ac:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 28 Aug 2023 09:29:46 -0400 (EDT) Message-ID: <95a4dd47f25addc0408a1016ecbe1ed18d9dab6d.camel@aura-online.co.uk> Subject: Re: Tuple and changes for m68k with -malign-int From: James Le Cuirot To: John Paul Adrian Glaubitz , Adhemerval Zanella Netto , Finn Thain Cc: libc-help@sourceware.org, debian-68k , linux-m68k Date: Mon, 28 Aug 2023 14:29:43 +0100 In-Reply-To: <87134fda9b761e3f81588d440242b9a4e986ddbf.camel@physik.fu-berlin.de> References: <10cbcb8a65639f88e7eeb503fd02df172bc46a07.camel@physik.fu-berlin.de> <80a52487-3105-ed5b-a1eb-ec1a0689ef21@linux-m68k.org> <4b4fe9c56dfdb8ec74150413cfc211d70243eb7e.camel@physik.fu-berlin.de> <87134fda9b761e3f81588d440242b9a4e986ddbf.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-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_COUK,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 2023-08-28 at 14:50 +0200, John Paul Adrian Glaubitz wrote: > Hi Adhemerval! >=20 > 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 dif= ferent > > loader and the question: will it be interoperable with current m68k ABI= in the=20 > > sense that i686 is interoperable with x86_64? It would allow to keep ol= d binaries > > running, similar to what old ABI did for 32 to 64 bits transition. >=20 > OK. To that, I would add: what old binaries? Linux on m68k is very obscure thes= e days, with Gentoo, Debian, and NixOS being the only major distributions sti= ll supporting it. As the Gentoo m68k maintainer, I would not expect users to b= e 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 probab= ly 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 sys= tem on my 16-bit aligned one and nothing broke. I then tried the reverse and sa= w 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 Schwa= b) where > > compiler changed some internal defined flags and it was not reflected o= n glibc > > (for a short, it seems that -mcpu=3D680X0 does not already define __mc6= 8020__). > > The build fix is straightforward, but it raised question whether someth= ing > > 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: > >=20 > > 949 FAIL > > 3344 PASS > > 99 UNSUPPORTED > > 16 XFAIL > > 2 XPASS > >=20 > > I guess the math failures are from the extra rounding and exception tes= ting, which=20 > > requires a fully compliant IEEE 754 fp unit (which I guess m68k does no= t provide). > > The last m68k testsuite report where from 2.26 release [1] running unde= r ARAnyM, > > which shows the port is a better shape. >=20 > 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 suppo= rt than > QEMU, so if you want to have more accurate results, you should test on AR= AnyM. 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=20 > > glibc tests to fail to build (since it assumes __DEC_EVAL_METHOD__ equa= l 0). This > > again raised questions on how the math library would behave depending o= f the target > > chip. > >=20 > > 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 f= ollow the > > MIPS mess and have 28 different ABIs that fails to be fully interoperab= le; 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; an= d move > > everything to new ABI. >=20 > 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 su= pport > 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= .