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 893953858D33 for ; Mon, 28 Aug 2023 12:46:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 893953858D33 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 1qabd7-000Tv1-N3; Mon, 28 Aug 2023 14:46:05 +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 1qabd7-002fgI-8s; Mon, 28 Aug 2023 14:46:05 +0200 Message-ID: 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 14:46:04 +0200 In-Reply-To: References: <10cbcb8a65639f88e7eeb503fd02df172bc46a07.camel@physik.fu-berlin.de> <5F114C03-5320-485F-86E3-946A334F16D1@arcor.de> <99aacdf62e82c8c4244e47052d5661df7417a47a.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: On Mon, 2023-08-28 at 12:11 +0000, Richard wrote: >=20 > On August 28, 2023 10:57:25 AM UTC, John Paul Adrian Glaubitz wrote: > > 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 tool= s > > > to pay attention to portability. > >=20 > > Portable shouldn't mean having to accommodate for unreasonable design d= ecisions > > of other developers. It's perfectly fine to assume 32-bit natural align= ment on > > a 32-bit platform and I don't think it's fair to put the burden of adop= ting for > > unusual design decisions on to upstream projects. >=20 > Assuming anything that is not declared by the c standard is not good imho= . The C > lang is well known for its pitfalls and the basic binary tools ought not = to set > bad precedents ignoring those.=20 >=20 > It is also reasonable to assume that on modern hw cache is filled in bloc= ks of perhap > 1k or more and thus "unnatural" alignment might actually help performance= because more > fits into that one data burst. This is a very academic discussion really and doesn't really solve the prob= lem we're seeing. We're here to solve a technical problem, not to discuss whether som= ething is according to the C standard. Upstream projects decide on their own what maintenance burden they're willi= ng to accept and which not. If they don't think it's reasonable to accommodate for the s= pecific m68k alignment requirements, the burden to keep these packages working are on th= e distribution maintainers meaning that I will have to continue spending time unbreaking p= ackages like OpenJDK in Debian which I prefer not having to in the future. Adrian --=20 .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913