From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id 94A063858409 for ; Fri, 21 Jul 2023 14:30:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 94A063858409 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id D5B5A92009C; Fri, 21 Jul 2023 16:30:55 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id CE71192009B; Fri, 21 Jul 2023 15:30:55 +0100 (BST) Date: Fri, 21 Jul 2023 15:30:55 +0100 (BST) From: "Maciej W. Rozycki" To: YunQiang Su cc: Richard Sandiford , Nick Clifton , YunQiang Su , binutils@sourceware.org, xry111@xry111.site, jiaxun.yang@flygoat.com Subject: Re: [PATCH v4 1/2] MIPS: support mips*64 as CPU and gnuabi64 as ABI In-Reply-To: Message-ID: References: <20230414072046.1639896-1-yunqiang.su@cipunited.com> <20230418140019.2195551-1-yunqiang.su@cipunited.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1163.4 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE 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 Fri, 21 Jul 2023, YunQiang Su wrote: > > > > So this has changed the default ABI from o32 to n32 for `mipsisa64-*-*' > > > > > > I think that maybe you have a misunderstanding. > > > 1. It is *not* for `mipsisa64-*-*', it is for `mipsisa64-*-gnuabi64' > > > 2. It is not from O32 to N32. It is from N32 to N64. > > > > Well test results say otherwise. Please build yourself binutils for > > `mipsisa64-linux' and see what output format it uses with and without this > > change. > > Ohh you are right, while, does mips*-linux without ABI section really matter? > I never hear about it is used for any real system. You may not have heard about it, but someone has added these machine specifiers for a reason and I reckon seeing at least `mipsisa64-*-*' ones used at one point, maybe at MTI back in ~2005. Here the "isa64" suffix only specifies the ISA level (just as with "isa32", etc.) and not the ABI such as with the "64" suffix. It may have even been before we had NewABI support in the first place, so the semantics for `mipsisa64-*-*' had to stay for backwards compatibility already back then. And I do remember the days and the issues around merging NewABI stuff; if MTI weren't so slow with defining it, we could have ended up with NUBI instead rather than this old IRIX stuff, not necessarily adequate for embedded use and with its sole advantage that it was already well-defined then, so the community took lead and merged NewABI support behind MTI's back. > Ohh, yes, my patch switch the default output of mips*isa64-linux to > N32 from O32. > I believe that it is an correct modification. Maybe, but this is changing what we've had for 20+ years, so it must not be done without proper consideration, documentation, and likely a NEWS entry, as this is a user-visible change of semantics. You can't just decide unilaterally, especially on something that's been out there for such a long time. I think this close to 2.41 release the best course of action may be reverting the change after all on trunk/2.41, and then re-applying the uncontroversial part on trunk only. This will prevent Nick from being held with the release and we can decide what to do with the rest. It would unblock me with accepting your outstanding bug fix as well, also for 2.41. And I wonder if there's more that needs to be undone for 2.41, so that it can be then handled properly with 2.42, especially given the large quantity of regressions introduced, which may not necessarily be solely due to the lack of update to the testsuite and could be a sign of actual problems introduced with the tools themselves. I'd prefer to have results with 2.41 that are no worse than as at 32f1c80375eb^ TBH. Maciej