From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 104DE3858D20 for ; Fri, 3 Feb 2023 14:08:59 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 104DE3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C14CC1FB; Fri, 3 Feb 2023 06:09:40 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.99.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BC94D3F71E; Fri, 3 Feb 2023 06:08:57 -0800 (PST) From: Richard Sandiford To: YunQiang Su Mail-Followup-To: YunQiang Su ,YunQiang Su , gcc-patches@gcc.gnu.org, macro@orcam.me.uk, jiaxun.yang@flygoat.com, richard.sandiford@arm.com Cc: YunQiang Su , gcc-patches@gcc.gnu.org, macro@orcam.me.uk, jiaxun.yang@flygoat.com Subject: Re: [PATCH] MIPS: use arch_32/64 instead of default_mips_arch References: <20230203090544.2528175-1-yunqiang.su@cipunited.com> Date: Fri, 03 Feb 2023 14:08:56 +0000 In-Reply-To: (YunQiang Su's message of "Fri, 3 Feb 2023 21:23:11 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-34.5 required=5.0 tests=BAYES_00,BODY_8BITS,GIT_PATCH_0,KAM_DMARC_NONE,KAM_DMARC_STATUS,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: YunQiang Su writes: > Richard Sandiford via Gcc-patches > =E4=BA=8E2023=E5=B9=B42=E6=9C=883=E6=97=A5=E5=91=A8=E4=BA=94 20:29=E5=86= =99=E9=81=93=EF=BC=9A >> >> YunQiang Su writes: >> > The value of default_mips_arch will be always used for -march by defau= lt, >> > no matter what value is given to -mabi. >> > It will produce abnormal elf file like: >> > ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV) >> >> Is that really wrong though? There's nothing in principle that >> prevents a 64-bit ISA being used with a 32-bit ABI, even in the >> object file's metadata. >> > > To make sure that there is no misunderstanding. > The "wrong" format is > ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV) > ^^ > and the "correct" O32 ABI file is > ELF 32-bit LSB relocatable, MIPS, MIPS32 rel2 version 1 (SYSV) > ^^ > and the linker refuses to interlink them together. > > Do you mean that the "wrong" format is quite interesting? > Yes, While this format is never used at all. My point was that there is nothing wrong in principle with creating an o32 executable that has a 64-bit rather than a 32-bit ISA (since the 64-bit ISAs are pure extensions of 32-bit ISAs). Doing that is even useful in some cases. For example, MIPS4+O32 is a useful combination, even though MIPS4 is a 64-bit ISA. Same for Octeon3+O32, etc. So is the linker behaviour really correct? Doesn't it mean that Octeon3 O32 binaries are link-incompatible with MIPS32 o32 binaries? >> > So we use with_arch_32 and with_arch_64 instead of default_mips_arch >> > for all mipsisa[32,64]rN triples. >> >> I agree there's no benefit to using a stock MIPS64rN ISA over >> a stock MIPS32rN ISA with a 32-bit ABI, and the patch is only >> changing those cases. But things are different when using >> (say) MIPS4 with a 32-bit ABI, or a 64-bit processor that has >> proprietary extensions. >> >> And, for example, a mips-linux-gnu toolchain would (IIRC) require >> an -march as well as an -mabi in order to generate 64-bit code. >> There would be no implicit selection of a new -march. >> > > In fact, no: if we wish to use the default march of GCC configured, > we can use -mabi=3D64 only. > > $ mipsel-linux-gnu-gcc -mabi=3D64 -c xx.c && file xx.o > xx.o: ELF 64-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV), > not stripped Ah, OK, thanks for the correction. I obviously misremembered. > There does be a problem: > $ mipsel-linux-gnu-gcc -mabi=3D32 -march=3Dmips64r2 -c xx.c && file xx.o > xx.o: ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV), > not stripped > = ^^ >> I'm not opposed to the patch. I just think we should be clear >> about the underlying principle. If it's just that all MIPS32/64rN >> toolchains should behave in the same way (like the sde and mti ones >> do), then the patch looks good. But I don't think we should create >> a general principle that -mabi determines/changes/downgrades -march. >> > > In fact, I prefer what x86 does now: > $ gcc -m32 -march=3Dhaswell -c -O3 xx.c && file xx.o > xx.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stri= pped > > But MIPS does like: > $ mipsel-linux-gnu-gcc -mabi=3D32 -march=3Docteon -c yy.c && file yy.o > yy.o: ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV), > not stripped > = ^^ > $ mipsel-linux-gnu-gcc -mabi=3D32 -march=3Dmips64r2 -c yy.c && file yy.o > yy.o: ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV), > not stripped > = ^^ > > I hope I can fix this problem for MIPS, although I have no idea how to > do so yet. The current MIPS behaviour is what I'd expect though, given the command lines. file doesn't tell the full story. The ELF flags should also distinguish between the -march=3Docteon and -march=3Dmips64r2 cases. Thanks, Richard > >> Thanks, >> Richard >> >> > >> > gcc/ChangeLog: >> > * config.gcc: use with_arch_32 and with_arch_64 instead of >> > default_mips_arch for mipsisa[32,64]rN triples. >> > --- >> > gcc/config.gcc | 21 ++++++++++++++------- >> > 1 file changed, 14 insertions(+), 7 deletions(-) >> > >> > diff --git a/gcc/config.gcc b/gcc/config.gcc >> > index f0958e1c959..0b6d093d847 100644 >> > --- a/gcc/config.gcc >> > +++ b/gcc/config.gcc >> > @@ -2518,13 +2518,16 @@ mips*-*-linux*) = # Linux MIPS, either endian. >> > extra_options=3D"${extra_options} linux-android.opt" >> > case ${target} in >> > mipsisa32r6*) >> > - default_mips_arch=3Dmips32r6 >> > + with_arch_32=3D"mips32r6" >> > + with_arch_64=3D"mips64r6" >> > ;; >> > mipsisa32r2*) >> > - default_mips_arch=3Dmips32r2 >> > + with_arch_32=3D"mips32r2" >> > + with_arch_64=3D"mips64r2" >> > ;; >> > mipsisa32*) >> > - default_mips_arch=3Dmips32 >> > + with_arch_32=3D"mips32" >> > + with_arch_64=3D"mips64" >> > ;; >> > mips64el-st-linux-gnu) >> > default_mips_abi=3Dn32 >> > @@ -2540,22 +2543,26 @@ mips*-*-linux*) = # Linux MIPS, either endian. >> > ;; >> > mipsisa64r6*-*-linux-gnuabi64) >> > default_mips_abi=3D64 >> > - default_mips_arch=3Dmips64r6 >> > + with_arch_32=3D"mips32r6" >> > + with_arch_64=3D"mips64r6" >> > enable_mips_multilibs=3D"yes" >> > ;; >> > mipsisa64r6*-*-linux*) >> > default_mips_abi=3Dn32 >> > - default_mips_arch=3Dmips64r6 >> > + with_arch_32=3D"mips32r6" >> > + with_arch_64=3D"mips64r6" >> > enable_mips_multilibs=3D"yes" >> > ;; >> > mipsisa64r2*-*-linux-gnuabi64) >> > default_mips_abi=3D64 >> > - default_mips_arch=3Dmips64r2 >> > + with_arch_32=3D"mips32r2" >> > + with_arch_64=3D"mips64r2" >> > enable_mips_multilibs=3D"yes" >> > ;; >> > mipsisa64r2*-*-linux*) >> > default_mips_abi=3Dn32 >> > - default_mips_arch=3Dmips64r2 >> > + with_arch_32=3D"mips32r2" >> > + with_arch_64=3D"mips64r2" >> > enable_mips_multilibs=3D"yes" >> > ;; >> > mips64*-*-linux-gnuabi64 | mipsisa64*-*-linux-gnuabi64)