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 7C53B3858D32 for ; Sun, 20 Aug 2023 15:21:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7C53B3858D32 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 57FBC92009C; Sun, 20 Aug 2023 17:21:01 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 4A14292009B; Sun, 20 Aug 2023 16:21:01 +0100 (BST) Date: Sun, 20 Aug 2023 16:21:01 +0100 (BST) From: "Maciej W. Rozycki" To: YunQiang Su cc: Ian Lance Taylor , Cary Coutant , YunQiang Su , binutils@sourceware.org Subject: Re: [PATCH] MIPS: recoginze mipsisa64 as 64bit CPU In-Reply-To: Message-ID: References: <20230815104821.41855-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=-1169.3 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,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: [Ian, Cary -- please see my notes about GOLD at the end; I'll appreciate your input.] On Sun, 20 Aug 2023, YunQiang Su wrote: > > The change description has to be explicit in that we only refer to Linux > > configurations here, as it doesn't change the semantics of `mipsisa64*' > > CPUs for other OSes. And it's not that we don't consider the CPU 64-bit > > for `mipsisa64*-*-linux*' configurations. We just don't use a 64-bit ABI > > by default. Finally there's no need to repeat the rules for ABI selection > > as we just follow the existing ones for `mips64*-*-linux*' configurations. > > > > How about: > > > > MIPS: Use a 64-bit ABI by default for `mipsisa64*-*-linux*' targets > > > > I use ABIs here, since they are both N32 and/or N64. But only one at a time, hence the singular. You can't have n32 and n64 as the default both at a time (in which case you'd use the plural form). I realise your view might be a consequence from how you express things in your native language, but this is how English grammar works (as how it is the case with many if not all of the European languages, most of which derive from a common ancestor in the Middle East thousands of years ago). NB mind the lowercase "n" in n32 and n64. I realise people started mixing things up later on, but these were the correct spellings as the ABIs were invented (along with o32 and less officially o64) back in 1990s. There's no need to spread the mixed up form. > > > diff --git a/gold/configure.tgt b/gold/configure.tgt > > > index 4b54e08d27f..d09bb76ef02 100644 > > > --- a/gold/configure.tgt > > > +++ b/gold/configure.tgt > > > @@ -153,13 +153,27 @@ aarch64*-*) > > > targ_big_endian=false > > > targ_extra_big_endian=true > > > ;; > > > -mips*el*-*-*|mips*le*-*-*) > > > +mips64*el*-*-* | mipsisa64*le*-*-*) > > > + targ_obj=mips > > > + targ_machine=EM_MIPS_RS3_LE > > > + targ_size=64 > > > + targ_big_endian=false > > > + targ_extra_big_endian=true > > > + ;; > > > +mips*el*-*-*) > > > > You are removing the `mips*le*-*-*' configuration here. It may well be > > the right move given that no other binutils component has it, but it has > > to be a separate change. > > > > You are right. I will add it back. I suggest the opposite, that is to remove it with a separate patch, as it couldn't have been a usable configuration ever. It must have slipped through review. > > > targ_obj=mips > > > targ_machine=EM_MIPS_RS3_LE > > > targ_size=32 > > > targ_big_endian=false > > > targ_extra_big_endian=true > > > ;; > > > +mips64*-*-* | mipsisa64*-*-*) > > > + targ_obj=mips > > > + targ_machine=EM_MIPS > > > + targ_size=64 > > > + targ_big_endian=true > > > + targ_extra_big_endian=false > > > + ;; > > > > Also you're adding new 64-bit MIPS support to GOLD here, so it has to be > > a separate patch too from the changes to the other binutils components. > > Is it a working configuration for GOLD even? Doesn't it need to have > > In fact, the current configure.tgt makes something wrong, if we configure > it with --with-targets=mips64-linux-gnuabi64. > https://buildd.debian.org/status/fetch.php?pkg=binutils-mipsen&arch=amd64&ver=10%2Bc5&stamp=1692086940&raw=0 > > That's why I'd like to put them in a single patch. You can fix GOLD to match the rest of the tools first, i.e. add support for `mips64*el-*-linux*' and `mips64*-*-linux*' only with a preparatory patch before the rest of the series to be considered. This way you won't add an inconsistency. This seems like the best approach, as we can shake out the issues there with the conventional n32-by-default configurations before adding n64-by-default support treewide. > > `targ_extra_size' also set? > > Maybe no. > Since `configure.tgt` is used for --enable-targets=xx,yy option. > WIth this option, only the list extra targets should be support. > If we set it, 32bit targets will be supported anyway. Why do other targets such as `x86_64*', `sparc64-*', `powerpc64le-*', `aarch64*-*', etc. set it then? > If user wants to support all targets, they need to use > --with-targets=all You mean `--enable-targets' I guess, but that's no news of course. But other multiple-ABI 64-bit configurations (and some 32-bit ones) chose to have their 32-bit counterparts always included in GOLD, as we do too in BFD, GAS, LD. So why do you want GOLD to be different? Cc-ing GOLD maintainers in case they want to chime in as GOLD is not my usual part of interest in binutils. Maciej