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 886CC3858D33 for ; Mon, 28 Aug 2023 10:57:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 886CC3858D33 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 1qaZvy-0043dq-Ta; Mon, 28 Aug 2023 12:57:26 +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 1qaZvy-002Dny-Dm; Mon, 28 Aug 2023 12:57:26 +0200 Message-ID: <99aacdf62e82c8c4244e47052d5661df7417a47a.camel@physik.fu-berlin.de> Subject: Re: Tuple and changes for m68k with -malign-int From: John Paul Adrian Glaubitz To: Richard , debian-68k@lists.debian.org, James Le Cuirot Cc: libc-help@sourceware.org, linux-m68k Date: Mon, 28 Aug 2023 12:57:25 +0200 In-Reply-To: <5F114C03-5320-485F-86E3-946A334F16D1@arcor.de> References: <10cbcb8a65639f88e7eeb503fd02df172bc46a07.camel@physik.fu-berlin.de> <5F114C03-5320-485F-86E3-946A334F16D1@arcor.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: On Sat, 2023-08-26 at 19:24 +0000, Richard wrote: > > Not only mold but also most notably the following projects: >=20 > a linker that is broken by a slightly unusual alignment isn't exactly a > prime example.. if any project I would expect linkers and binary tools > to pay attention to portability. Portable shouldn't mean having to accommodate for unreasonable design decis= ions of other developers. It's perfectly fine to assume 32-bit natural alignment= on a 32-bit platform and I don't think it's fair to put the burden of adopting= for unusual design decisions on to upstream projects. This kind of attitude was certainly one of the reasons why the Itanium arch= itecture failed. Its designers made weird decisions which made life hard for upstrea= m developers and most of them were happy when the architecture was finally abandoned. > > - LLVM >=20 > Ok .. too big to complain about.. and see above. It's also nearly impossible to make LLVM work with 16-bit alignment because= the code uses certainly packed data types which require 32-bit alignment or higher. > > - OpenJDK >=20 > OpenJDK has not only that one problem. That's an unnecessary remark that is not helpful here. Please don't do that= ! > > It's a regular occurrence that a package doesn't build on m68k due to i= t's unusual > > default alignment.=20 >=20 > Unfortunately. Some time ago m68k was not the only one with this problem? Well, as mentioned above, other architectures with weird requirements such = as Itanium have been abandoned and most upstream projects were happy when this finally= happened. > > Thus, in order to keep the port alive in the future, I think > > switching to 32-bit alignment by default is inevitable. > >=20 >=20 > Ok.=20 >=20 >=20 > > > We need to > > > break the ABI anyway with time_t going 64-bit, so it makes sense to d= o these > > > two things at the same time. >=20 >=20 > What exactly will be broken? Afaics kernel ABIs have been since long pret= ty carefully > designed to avoid this problems and noone of the mentioned examples shoul= d touch them anyway.=20 >=20 > Thus.. is there any need to change the kernel ABI? I don't think this mandates changes to the kernel ABI. Adrian --=20 .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913