From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-f177.google.com (mail-pg1-f177.google.com [209.85.215.177]) by sourceware.org (Postfix) with ESMTPS id 4DFA73858D20 for ; Fri, 3 Feb 2023 13:23:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4DFA73858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pg1-f177.google.com with SMTP id s67so3615467pgs.3 for ; Fri, 03 Feb 2023 05:23:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding: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=Bm94CptGQTqAqeTsJYPDO5IQ5fv/x/HizIVFAzk+3dQ=; b=Ybkou+Br67b4wWG+xUzIbbfsFJ+btQNASxqTrdGsSSP50kfZQ+7ykRf5F1rmA8vn1C Tr0zR9k9ppaOxfPw3+OknV/PvUhQVAaetnDV74QwdY09sTPtAqAyfyf03dICeikZ0bQs KQ/D5GmHx9eOAnTqgkraEkEq6eSVm2bAew4c2m5jov9kb1j9MUJ20019qEbw1E66JaIc QyKa7cPVJtaRyfsKMX1434VEBvFCHamQRqSIshv0Cu8F9bArv8RXIURP1wD7pMSW3N2+ Y4tKB0URc4FzIlL8VOOJlXh9elFQqQFTDjNaTxaD9td31M2YEtNKdr/fVyj5YlfOqXw4 wXWA== X-Gm-Message-State: AO0yUKUA//rMLx6vLa2whcdK0lwC4y9BwQ5vsRLb8KF1iFCW8KZpLoH3 X97Xf6cOcyegvS12PJday/5DNbqvnuzJFmnQ5/w= X-Google-Smtp-Source: AK7set9OXzX69DMyCFwz6VmnCuocfAtGY7CuT03FUoD9xQfKVJH4i/DF5ZQUH1/UFRz7yb4DeKpEUrCDjxOvuarHsqQ= X-Received: by 2002:aa7:8a5a:0:b0:592:5ec5:6713 with SMTP id n26-20020aa78a5a000000b005925ec56713mr2024195pfa.30.1675430602636; Fri, 03 Feb 2023 05:23:22 -0800 (PST) MIME-Version: 1.0 References: <20230203090544.2528175-1-yunqiang.su@cipunited.com> In-Reply-To: From: YunQiang Su Date: Fri, 3 Feb 2023 21:23:11 +0800 Message-ID: Subject: Re: [PATCH] MIPS: use arch_32/64 instead of default_mips_arch To: Richard Sandiford , YunQiang Su , gcc-patches@gcc.gnu.org, macro@orcam.me.uk, syq@debian.org, jiaxun.yang@flygoat.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-8.3 required=5.0 tests=BAYES_00,BODY_8BITS,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,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: 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 defaul= t, > > 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. > > 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 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 stripp= ed 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. > 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)