From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by sourceware.org (Postfix) with ESMTPS id C5B2B3858D39 for ; Sun, 27 Aug 2023 00:47:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C5B2B3858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=linux-m68k.org Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id DB5CE5C00B9; Sat, 26 Aug 2023 20:47:25 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sat, 26 Aug 2023 20:47:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc: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=1693097245; x=1693183645; bh=Fp09O59ANftag CTt83PACfCjbcHLW1cdhEBznSYXhmc=; b=dXuNePy0h4eQIViQe6ImppenPLs+s A89LuhkLEVJZVBDvft+JyjHN2aHWLL4yl2zywyv5cvYIx8HfJVUMhPFD9iFTe2Az fktD5VhupZnoUm66bvV9cSwpDsZIQgnTte9W2xEvKj5m7JW7E4dS+U8nHqwWzvZP MV4MMmd4LripuSSutdTb1l9j3c9c2K8ZSjO8rKS+8PfEZ7AnGmGR8IppMLBizk8W aEa3A8hvYPKQz55uIrJ6fDIqkRESGh+oZbyTyPhAFlPha3WG9N6m4NiEy3IAe6BG Ul0qa+ZBlKYj3iFqrV3DgdukkJ5SHHPx/skzLwMXqBJtz6k5mMrhDxjrw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudefuddgfeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevufgjkfhfgggtsehttdertddttddvnecuhfhrohhmpefhihhnnhcu vfhhrghinhcuoehfthhhrghinheslhhinhhugidqmheikehkrdhorhhgqeenucggtffrrg htthgvrhhnpeelueehleehkefgueevtdevteejkefhffekfeffffdtgfejveekgeefvdeu heeuleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hfthhhrghinheslhhinhhugidqmheikehkrdhorhhg X-ME-Proxy: Feedback-ID: i58a146ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 26 Aug 2023 20:47:23 -0400 (EDT) Date: Sun, 27 Aug 2023 10:46:54 +1000 (AEST) From: Finn Thain To: John Paul Adrian Glaubitz cc: James Le Cuirot , libc-help@sourceware.org, debian-68k , linux-m68k Subject: Re: Tuple and changes for m68k with -malign-int In-Reply-To: <10cbcb8a65639f88e7eeb503fd02df172bc46a07.camel@physik.fu-berlin.de> Message-ID: <80a52487-3105-ed5b-a1eb-ec1a0689ef21@linux-m68k.org> References: <10cbcb8a65639f88e7eeb503fd02df172bc46a07.camel@physik.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_NONE,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 Sat, 26 Aug 2023, John Paul Adrian Glaubitz wrote: > On Sat, 2023-08-26 at 09:53 +0100, James Le Cuirot wrote: > ... > > Not only mold but also most notably the following projects: > > - LLVM > - Firebird Database > - OpenJDK > - Various Qt packages > And potentially more in the future, which may be anticipated on the basis that "those users don't need a stable ABI any more, so let's just ignore the portability issues in our code and leave the problem to the distros and toolchain developers". That is the precedent you would set. Moreover, why is it that only a few developers have a problem with making explicit their decisions regarding alignment of shorts? What actual pain does it cause them to accept a patch to make their struct layouts plain? > > It goes against the traditional ABIs, but practically no m68k Linux > > binaries are published outside of distributions, so this not a > > concern. It is of concern to some users (though not all, apparently). > > We need to break the ABI anyway with time_t going 64-bit, so it makes > > sense to do these two things at the same time. > > Fully agreed. > If the kernel breaks the ABI, that's a bug, not an excuse. Either you're okay with proliferation of incompatible binaries and tools or there are some criteria (yet to be identified AFAIK) which permit this bug. It's not difficult to foresee fragmentation because it follows from the manpower shortage. There will always be sufficient manpower to produce a break that pleases a few. There may never be enough manpower to produce a stable ABI that pleases everyone for the foreseeable future. > > I think -gnu32 sounds very reasonable. You do? I think 32 is misleading in the absence of 16-bit or 64-bit variants, and -gnu is misleading if other tooling like LLVM already supports malign-int. Moreover, it's impossible to align to a bit count in general. Not that you'd want to -- it's actually the natural alignment of shorts that is at issue, AIUI. So, for naming purposes, the proposal might be described as either the ABI du jour (leading to -abi23 for 2023) or the new ABI for ever (leading to -abin as in -gnuabin32 on MIPS). If it's the former, perhaps you should not push it upstream. If it's the latter, perhaps this redesign should seek to address real shortcomings with the existing ABI, including problems which (for all I know) may have entirely prevented some people from using it thus far. That is, it should consider silicon beyond 680x0.