From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id 932353858D32 for ; Sun, 20 Aug 2023 16:01:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 932353858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x62c.google.com with SMTP id d9443c01a7336-1bc0d39b52cso14979475ad.2 for ; Sun, 20 Aug 2023 09:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1692547272; x=1693152072; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=yaSxfnDLyYMo/eZ1EE/Sy/0OPOOQQwtp7pDn+CIUwCg=; b=Lv1X6ewaLBd5nTy4J2CtwVQMUpZzgiYla6wFOW80y65ioVpnR6q5m99pNinJ3g5G+G q3EbV8KSacafLjL0vgoUg9uOYsB6PFf7EkwFacIe1JYZeQzTHyVhSxA5L43yHbZceK6n gtnT8OjEP1VcDUPgmixZ3Rd61k6M5fbXoZ5vO1JumSu3UifdnPYTMeQxAHk111Kzg4q7 5hEQeyTiO4gHM0+eCvnQGhrfgcd4aOPl6yLMO+qtWd6MEWX1HPTF5rxna+GE+42Rojvo dMkIw9ekRaYpIjeEV4fGD/7Yi+qNxACIjLo51eoTwPs/swnYd9Lk0OQvoefxEl4pTRJP oMAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1692547272; x=1693152072; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=yaSxfnDLyYMo/eZ1EE/Sy/0OPOOQQwtp7pDn+CIUwCg=; b=loYJB4DXhrwZDNCqdPpsNPRjIQm5YS/LWt/9AJD8iBXHHwTHAmDbav7zgShCwZ9yP8 uOVWUN599+XjIuPdekdDhUyaE0jKOA2RaRE9Egbe4lz2JocZdqn6Y9Xt7fMcxcoGHu9h XNCbz6EOyxKMry2nWSzVZazl0WSaz98hof0Lag7XMGUkLMTqY/ELU2lv4TibrocKoXh5 Xw/ziU2H6SzbbGlTxSYaE1p7goEGuHp0JWkwTnBnH513tlnxL7aP3gI7bi6sAspUM65o hdSRBXTOrWJFoO4jY7ZAcpr8IHbeMF0ArGi8Hu8DRu+JFDuRQuTeXpnTRuhVgSc9hhQl RqsQ== X-Gm-Message-State: AOJu0Yzcb6w11QWgrG6CK+7oW3e3nFEQIQqCaRZC2n18+sesHOU1ouE6 zfSUt9GOg0vQAuIedhftV0IBFTq96mFCIXnM/cU= X-Google-Smtp-Source: AGHT+IGS/ZNVsNot9wu8PyOrRjnV1SxTrjOR96hWk+vQ1UIIMcnKgtO1VoBiMxeeJxguSv61y/Pbf53gq7RR1Orltfc= X-Received: by 2002:a17:903:1109:b0:1bb:3a7:6af7 with SMTP id n9-20020a170903110900b001bb03a76af7mr3590769plh.23.1692547271013; Sun, 20 Aug 2023 09:01:11 -0700 (PDT) MIME-Version: 1.0 References: <20230815104821.41855-1-yunqiang.su@cipunited.com> In-Reply-To: From: YunQiang Su Date: Mon, 21 Aug 2023 00:00:59 +0800 Message-ID: Subject: Re: [PATCH] MIPS: recoginze mipsisa64 as 64bit CPU To: "Maciej W. Rozycki" Cc: Ian Lance Taylor , Cary Coutant , YunQiang Su , binutils@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,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: Maciej W. Rozycki =E4=BA=8E2023=E5=B9=B48=E6=9C=8820=E6= =97=A5=E5=91=A8=E6=97=A5 23:21=E5=86=99=E9=81=93=EF=BC=9A > > [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 L= inux > > > 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 sele= ction > > > as we just follow the existing ones for `mips64*-*-linux*' configurat= ions. > > > > > > 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). > Yes. You are right. I have not very clear about since I was in junior high school, when I started to learn English, ;) > I realise your view might be a consequence from how you express things i= n > 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=3Dfalse > > > > targ_extra_big_endian=3Dtrue > > > > ;; > > > > -mips*el*-*-*|mips*le*-*-*) > > > > +mips64*el*-*-* | mipsisa64*le*-*-*) > > > > + targ_obj=3Dmips > > > > + targ_machine=3DEM_MIPS_RS3_LE > > > > + targ_size=3D64 > > > > + targ_big_endian=3Dfalse > > > > + targ_extra_big_endian=3Dtrue > > > > + ;; > > > > +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. > OK, Send. > > > > targ_obj=3Dmips > > > > targ_machine=3DEM_MIPS_RS3_LE > > > > targ_size=3D32 > > > > targ_big_endian=3Dfalse > > > > targ_extra_big_endian=3Dtrue > > > > ;; > > > > +mips64*-*-* | mipsisa64*-*-*) > > > > + targ_obj=3Dmips > > > > + targ_machine=3DEM_MIPS > > > > + targ_size=3D64 > > > > + targ_big_endian=3Dtrue > > > > + targ_extra_big_endian=3Dfalse > > > > + ;; > > > > > > Also you're adding new 64-bit MIPS support to GOLD here, so it has t= o be > > > a separate patch too from the changes to the other binutils component= s. > > > 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 configu= re > > it with --with-targets=3Dmips64-linux-gnuabi64. > > https://buildd.debian.org/status/fetch.php?pkg=3Dbinutils-mipsen&arch= =3Damd64&ver=3D10%2Bc5&stamp=3D1692086940&raw=3D0 > > > > 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. > N32-or-N64 default is another topic for gold here, I guess. > > > `targ_extra_size' also set? > > > > Maybe no. > > Since `configure.tgt` is used for --enable-targets=3Dxx,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? > I have no idea. And in fact, I think that there is no standard way: i?86 doesn't enable 64bit support. while ppc does. For aarch64, I believe it should be a mistake, as it has no 32bit mode.( correct me if I am wrong. For me, I think that we should follow what users ask us to do. If they need to support more, they can use "--enable-targets". > > If user wants to support all targets, they need to use > > --with-targets=3Dall > > 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? > Adding all EL/EB/32/64 etc support sounds like a good idea. I didn't do this, due to the previous mips* ones not enabling 64 bit suppor= t. > Cc-ing GOLD maintainers in case they want to chime in as GOLD is not my > usual part of interest in binutils. > > Maciej --=20 YunQiang Su