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 169163858C53 for ; Sat, 26 Aug 2023 10:51:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 169163858C53 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 1qZqtQ-000jVt-Qt; Sat, 26 Aug 2023 12:51:48 +0200 Received: from dynamic-077-183-184-001.77.183.pool.telefonica.de ([77.183.184.1] helo=[192.168.1.11]) by inpost2.zedat.fu-berlin.de (Exim 4.95) with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (envelope-from ) id 1qZqtQ-0018Rp-D2; Sat, 26 Aug 2023 12:51:48 +0200 Message-ID: <10cbcb8a65639f88e7eeb503fd02df172bc46a07.camel@physik.fu-berlin.de> Subject: Re: Tuple and changes for m68k with -malign-int From: John Paul Adrian Glaubitz To: James Le Cuirot Cc: libc-help@sourceware.org, debian-68k , linux-m68k Date: Sat, 26 Aug 2023 12:51:39 +0200 In-Reply-To: References: 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: 77.183.184.1 X-ZEDAT-Hint: PO X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_BARRACUDACENTRAL,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: Hi James! On Sat, 2023-08-26 at 09:53 +0100, James Le Cuirot wrote: > I wasn't sure whether to send this to libc-alpha or here. This feels more= like > a request for help, so I decided to play it safe. :) I am CC'ing Debian's m68k mailing list and the Linux m68k kernel mailing li= st to make sure we're getting enough exposure. > The Debian m68k maintainers proposed building their packages with -malign= -int > last year, aligning to 32-bit instead of 16-bit, which improves compatibi= lity > with some projects and should give better performance on 68020+, at the c= ost > of slightly increased memory usage. The mold linker is at least one proje= ct > that has been shown to work after making this change where it previously > didn't. Not only mold but also most notably the following projects: - LLVM - Firebird Database - OpenJDK - Various Qt packages It's a regular occurrence that a package doesn't build on m68k due to it's = unusual default alignment. Thus, in order to keep the port alive in the future, I t= hink switching to 32-bit alignment by default is inevitable. > It goes against the traditional ABIs, but practically no m68k Linux binar= ies > 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 th= ese > two things at the same time. Fully agreed. > We in Gentoo fully support this idea. We had hoped that Debian would take= the > initiative, but we're not aware of any movement yet, and we're keen to ma= ke > this transition, so I'm here to get the ball rolling. We haven't had a larger discussion yet and I didn't want to impose any chan= ges before we have agreed on how to move forward. Thanks a lot for finally star= ting the discussion. > We think this warrants a new tuple, and we'd like to ensure that everyone= gets > 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 fla= g > actually affects floats and doubles too. I don't really care what it is > though, so feel free to suggest something totally different. I think -gnu32 sounds very reasonable. I'm actually also wondering what is = being used for other ports that are going to be rebuilt with 64-bit time_t. Maybe= we could use that naming scheme. I guess using "gnu32" for any 32-bit port wit= h 64-bit time_t might not be the obvious choice. So, while I like the gnu32 suffix, I would suggest we do some research firs= t to find out what the commonly used triplet change will be used for 32-bit ports swi= tching to 64-bit time_t. > 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 wh= at I > came up with here was a total guess. Thanks for already looking into the implementation details! > --- 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 >=20 >=20 > I did try this out, and it largely seemed to work, although processes > occasionally hung. Perhaps this was unrelated. >=20 > It was a while back now and I can't remember if I also built the Linux ke= rnel > with -malign-int. Does it need to match? Presumably it would at least giv= e the > same kind of performance benefit? I cannot comment on this at the moment, so let's wait for the more experien= ced m68k kernel and toolchain folks to chime in. > Thanks for helping to keep m68k alive. Thank you, too, and thanks for getting this rolling! Adrian --=20 .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913