From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) by sourceware.org (Postfix) with ESMTPS id 7D5313858C53 for ; Sat, 26 Aug 2023 08:53:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7D5313858C53 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 compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id AB8D23200900; Sat, 26 Aug 2023 04:53:35 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Sat, 26 Aug 2023 04:53:35 -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 :message-id:mime-version:reply-to:sender:subject:subject:to:to; s=fm3; t=1693040015; x=1693126415; bh=IhzhhWg8XBegFu6gHEIq9PJ+y 5GDXH3lBZZ/vkAShXk=; b=DKWC/T7dB5pwFulUotOHbnvcxEEEcOrkMBQvaawv7 iq22rL1yOOCilrjdZILzbjW4FOb3luKvXUoJ3FcrnrqpP874tuS3w06+Feuq2BRj I4soIz6xclySgeYeDAKnw/dDP8ur9CcvxhdBFjBQVOidkAMmDn/+mIBbUg5a9nvC 2sDxQCnix+V46t30NdZL0eC1SRNUSvTPCzgpRHJMKjihrGI33x39Z8A6knBrn7TT JpuVHiEFAF8sTt0ILGhML8tMCHu2QeBv9/ANinFmuDmxT6/+HIWFSiuGO6CZVCQJ E67/VBQ5PHIXD1W3eELvjexzglNJTVhE8kVY8JuArvT8g== 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:message-id:mime-version: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=1693040015; x=1693126415; bh=I hzhhWg8XBegFu6gHEIq9PJ+y5GDXH3lBZZ/vkAShXk=; b=ivUeiG/9P1J9JNAb/ q2IhmKPVZo1cExbfXtDT4/dSf1K0soC8PMNcCkeu5Yk9BFrckuff6lNqlLovPM8+ M9/rrAqDzALfQHDTX0HasoAZUBOB+HT3mI0XZjQWog0fb9wNE/44IDPYuSxdG4o0 bqySD/ehfE1dYY0NWPUC5soXLgIHVOmDPVCtzmqg5f1FIOn22sGRI2mWMO/HCngC SR46x9w7mfIjcI9xGbBpPFKLeS6EwIhkxf6uap3Ux5z+FtaOtRff+aocnzgIL4KN GgFHAlj2lx+8i+P943U5ng3lro8w7xrXgA/P8KByJnzDSt1odta8mzn6uToQkoOQ 4rVyg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudeftddgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkffuhffvvefftgfgfgggsehtqhertddtreejnecuhfhrohhmpeflrghmvghs ucfnvgcuvehuihhrohhtuceotghhvgifihesrghurhgrqdhonhhlihhnvgdrtghordhukh eqnecuggftrfgrthhtvghrnhepveetuddvgeegtdeggfegvdejteegtdffteelhfelgfff gefhffffgfeliefhleeunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomheptghhvgifihesrghurhgrqdhonhhlihhnvgdrtghordhukh X-ME-Proxy: Feedback-ID: i51cd41ac:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sat, 26 Aug 2023 04:53:34 -0400 (EDT) Message-ID: Subject: Tuple and changes for m68k with -malign-int From: James Le Cuirot To: libc-help@sourceware.org Cc: John Paul Adrian Glaubitz Date: Sat, 26 Aug 2023 09:53:30 +0100 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.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_COUK,RCVD_IN_DNSWL_LOW,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: Hello, I wasn't sure whether to send this to libc-alpha or here. This feels more l= ike a request for help, so I decided to play it safe. :) The Debian m68k maintainers proposed building their packages with -malign-i= nt last year, aligning to 32-bit instead of 16-bit, which improves compatibili= ty with some projects and should give better performance on 68020+, at the cos= t of slightly increased memory usage. The mold linker is at least one project that has been shown to work after making this change where it previously didn't. It goes against the traditional ABIs, but practically no m68k Linux binarie= s are published outside of distributions, so this not a concern. We need to break the ABI anyway with time_t going 64-bit, so it makes sense to do thes= e two things at the same time. We in Gentoo fully support this idea. We had hoped that Debian would take t= he initiative, but we're not aware of any movement yet, and we're keen to make this transition, so I'm here to get the ball rolling. We think this warrants a new tuple, and we'd like to ensure that everyone g= ets behind the same one. It is currently m68k-*-gnu. Perhaps it could be m68k-*-gnu32 or m68k-*-gnu32a? I considered gnu32i (for int), but the flag actually affects floats and doubles too. I don't really care what it is though, so feel free to suggest something totally different. Once that is agreed, I'm happy to put together the patch to automatically enable the flag for this tuple in GCC. The part I do need help with is necessary changes to glibc, if any. Assembly is not my area at all, so what= I came up with here was a total guess. --- a/sysdeps/m68k/crti.S 2022-07-29 23:03:09.000000000 +0100 +++ b/sysdeps/m68k/crti.S 2022-11-30 21:41:52.710135230 +0000 @@ -56,7 +56,7 @@ #endif =20 .section .init,"ax",@progbits - .align 2 + .p2align 2 .globl _init .hidden _init .type _init, @function @@ -74,7 +74,7 @@ #endif =20 .section .fini,"ax",@progbits - .align 2 + .p2align 2 .globl _fini .hidden _fini .type _fini, @function I did try this out, and it largely seemed to work, although processes occasionally hung. Perhaps this was unrelated. It was a while back now and I can't remember if I also built the Linux kern= el with -malign-int. Does it need to match? Presumably it would at least give = the same kind of performance benefit? Thanks for helping to keep m68k alive. Regards, Chewi