Message ID | 20230203090544.2528175-1-yunqiang.su@cipunited.com |
---|---|
State | New |
Headers |
Return-Path: <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6C9A9385842D for <patchwork@sourceware.org>; Fri, 3 Feb 2023 09:06:44 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from APC01-PSA-obe.outbound.protection.outlook.com (mail-psaapc01on2125.outbound.protection.outlook.com [40.107.255.125]) by sourceware.org (Postfix) with ESMTPS id E11F83858C52 for <gcc-patches@gcc.gnu.org>; Fri, 3 Feb 2023 09:06:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E11F83858C52 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=cipunited.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=cipunited.com ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LVK7yM2duEgxD2+hH/PF20owivkdLfdxxC8HcZTh4GnVoLuhmdA4rwdERZEKiwN1nH1RUGEUxFwpnEpgG1H8Iupp0NLNyxrD8RBcsfNmT/eQxWFnvMKL8AiCEoXCd2broEE0FHyOndDCaRrngQVO4LvcosXP3T2iGfUROnVVlnEq1KekgvkhTSEwxeTWTVk6p27G4TY8ekRyMfSKzL5Ex9JeRrbJIR13GhWUbNJ9d+pITTI1uyX/rdrMmiEnKs6Imo63rRxxpq9YSZO4StbEZDXstX+nIRPYdlTGNlfT3dgobiOAnznoj+v1fStDJVBptorX0rTEU6MBZrUx/B1MUA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=8vFjrM7CaCqJFEDpy6zQWH83h2zg09RXNRlsFJ4LjJc=; b=fDG3YlRGK1HxoIU/JyWkSlFsUjh90odDwRn0Nr2YBZRd3dSGBYMXnLAbyNOv2UrdrNF2YsK3lVZJhRe2O2mpx3aDudFmNfMFJG23zAVY0lhHtzJMCI2CLVDjQhZdAGbDzFURglRX3YzEzPPgZQJSahLke+VM4vzccI1vBxb+d9hfozoKyODDDCWYHJd/qQHUchdR76Riu8fx2/fVQ0hCtGqYaj6gX3SqTaz+Xh+swNXSu8D9v5rLUxThPVcHtKI83BlibX01IH/GoW6G/ZFfDLGQBmBu7+yr6rTNL912NOaM2uATnzG7OkQVi7irojn6JfsZ2AHeSQLg7oUZZGpqAg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cipunited.com; dmarc=pass action=none header.from=cipunited.com; dkim=pass header.d=cipunited.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cipunited.onmicrosoft.com; s=selector1-cipunited-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8vFjrM7CaCqJFEDpy6zQWH83h2zg09RXNRlsFJ4LjJc=; b=EwTACeRppttaL3WEq759FQ/42Uk9mVNO4Cf/l8qJXRDbdbfn8u7rbzoinfmETOiq9UvVPuBR6AoFzcmG7kVYdTwblVB8Srmuzgq+dsT6GzojrsOTCTuR6YYQzIHV7oVvy58FLeviRhcOQcreNE5HEqOdwD3hC6Leu9OZ/XXQMcI= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cipunited.com; Received: from TYZPR04MB6117.apcprd04.prod.outlook.com (2603:1096:400:25a::9) by KL1PR04MB6758.apcprd04.prod.outlook.com (2603:1096:820:d0::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6064.28; Fri, 3 Feb 2023 09:06:01 +0000 Received: from TYZPR04MB6117.apcprd04.prod.outlook.com ([fe80::b2cb:a598:3a7e:367a]) by TYZPR04MB6117.apcprd04.prod.outlook.com ([fe80::b2cb:a598:3a7e:367a%2]) with mapi id 15.20.6064.028; Fri, 3 Feb 2023 09:06:01 +0000 From: YunQiang Su <yunqiang.su@cipunited.com> To: gcc-patches@gcc.gnu.org Cc: macro@orcam.me.uk, syq@debian.org, jiaxun.yang@flygoat.com, YunQiang Su <yunqiang.su@cipunited.com> Subject: [PATCH] MIPS: use arch_32/64 instead of default_mips_arch Date: Fri, 3 Feb 2023 17:05:44 +0800 Message-Id: <20230203090544.2528175-1-yunqiang.su@cipunited.com> X-Mailer: git-send-email 2.30.2 Content-Transfer-Encoding: 8bit Content-Type: text/plain X-ClientProxiedBy: TYCP286CA0020.JPNP286.PROD.OUTLOOK.COM (2603:1096:400:263::12) To TYZPR04MB6117.apcprd04.prod.outlook.com (2603:1096:400:25a::9) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: TYZPR04MB6117:EE_|KL1PR04MB6758:EE_ X-MS-Office365-Filtering-Correlation-Id: a0e699a3-2199-4d7c-2d38-08db05c5dee9 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: sZJg4LBoBzvHFYj5tcok6vfj182vdLdXdcSb9hF+tljl50s/3WupBbpeZBNhM7hXmvmi0OO/Hbu8P7fSDfusBu8QrCK3HyJNW5aEIkPoOrw/+X7mKlLfa+vYDY06p/rBBOFkngJRsdiyweQKJj/uN2Ilsh0q1OK0py5FlCW+TIgXP9gDVyLMByIUGgRRVdTmd4PJzz0la9VpCuGUpT+YcFh5opSA1VANV6tB1Oewz3A5ARuFu7+R17wYw/JyabcRT3XbQJt5EQnHT/8/wWPwDErDLXYaUU6oVUUEJP4/1cDMrCCwRjSAtP0Xp2/uMLhIHN5eUK5NlQSiKErkzxtwWkDFEA3aJOW4LAKtvdLEyN6+XfVVnwSNEjlIjPZHj8iO3f/sYgPbYK8k7gkpjWAVuXw/ROwpk2AvQpxRhdu57tQKe6f6tLPIY6OZShPOIGFlixURAAzZi75TsM0w8MaBspw+mlsE6WAR3Fjouldn3mDy3WTURtfEIjeTcrTsh5DenpChyHAi+rhTGeU1/CajTfE7fHs7I/hE4i/EYpLGo3tfKtnSWsVTxNfbJfn1mHMSVG0MSkLKmibJlRPrS79wMYZtt+yLlB9YyUOle92dDjrdc4ZpvczNnycmNmLE2P0DkqS7ynm+iYKpwjxDLr1IVsv8ubEiSfQXGuaCnOu+0EG2UUGCxpo39BNQ+1ei78gyisCzqqC/+GRadvPAvaOZMw== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYZPR04MB6117.apcprd04.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(346002)(376002)(136003)(39830400003)(396003)(366004)(451199018)(52116002)(5660300002)(38350700002)(38100700002)(316002)(86362001)(41300700001)(66476007)(8936002)(4326008)(8676002)(66556008)(66946007)(6916009)(2616005)(83380400001)(36756003)(478600001)(6486002)(6666004)(107886003)(26005)(186003)(1076003)(6506007)(2906002)(6512007); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: oDHnOFbdyEy8IYMg8LUC/BWU5fXiZ2iyz/JgKGnnCjN/QpqqGRcMKTqEPTG19tF9nbstWnipy384+AjMDQ0LpD1TWpTteSBs+FsUL5J7y/LIgFf6kpZ9PEX++AvQ3fN3vywz1OegHlp08JAOe6rVeJZSSEC5tiIhOBEXA8lhrR+qDMkibruUiSPGwD7yCpf3fNLYCqLWkLXgyzdayXyuTQN1AIQDfHqhEYPNxakHiF1Q5wUOuOdLcteb8r5fx3A4OmlR5EWSasFgMav7QX0ySQ7FG3vlw/Cg04A9KMnjeFxeKRZY0ANVHaMkVGI8kXdiUV/tOPmt043Bp8/PqjLZUeGMWVZQo0tKjXy2ia187RrAJAMj+PlB9gx71cUn6NR5245NzknpAcX2AyClybv1frs0qlb3txEoj6qukOzJHKdilKw5B/v9fT0sViF1EzBE/yfYE9b3hX3zS4HiZDg3ho63MNFJWNuYktPZt2auMKMHSlLTKpCPBxM4VwwGY86Mq/apCOD8VO+XLC6FZGDtSHmET+dOCCSkmfoRNFP4cWTLi4MAHbGiDLuzLmXISPueHCpwhIaF5Cnrlu1hcy58cDWX+41HoMLDYBbMF3c2pvw2JSzOSsj3X47R8O0PcIGvsihHriUdmcpAnQonfGKRSmn8f9hR2MgRRza3V8AINHtwTXkJsSPv4m4wwYlHePyS5eXCVEj4CfsxZGK3iUJtmoqNsn4K2GvB87NeiCPL47v8LbDEl0S+HB48H0U921bXzl1woVkUMQu6H4X1hiCwsnuwfVQU1bQBXkDlt55IO8XiJAfHUK6w72VJLnACjdxUCVqx2WFNWl/Yhj2H0QBc5d9z53kaEC1Wo09GcvHib5m4kCxAi3ERos4zCmM1yPXdPgWdRGUyVRLCIQ1OI+l8dHt4o0OrXZ3ozxq9NoLojEtodNdHz99FjFVjTfc+vSONdtjhaPD2zlYDV5YmVLBJ74wzOCZ+wc/9ZTQ9HBBOEn71/3fOdoDhqFK3TiH58tyE4anjWlTb3ZPUM63jOITWQNu7JfjTCerGEtWCuo5bR58FaMta/sKDh+MSQmgUj3nKMBFVWY0PfqTG9yVSKxi9m8qdifcNyOwJS/wCsNmom62w7uADNz9F/bN/gmeoeevE5OxR0TzSdQED130XSQ+mBGboCDNTwBxvX0YF0ZAu/b4oNshVt4USJwvPWdkJjaYAFXfTVo/6KJtgt7AaCr+M/PPRLAD0lQHPtpTkY7cfQCUk7cdjQgn1Ji61XaE/wCFqGgg7zdD6zcgyT7L8HsT68OsqAUcC7avNB7vDxAGeD0AsE3/X+h/0LOu12O7iZ+cKW5XQ+y0Nd7UBjYFn8IyaHYFMyWUqyiPfkNupuMeWOTRDotwAWeVPYugBKAxnfo95jqg7d6vrOdq+PUwJrOhk+nLO+SBDd3k9nbpuYWeU/RhkdAUZ2mZZba66VHXSfPMq5XCA6MJw87jaaCxrcmWoNOw5lihI4mPv6fXNAXwdxzyGwDYDNGL1qzBwefmKfBUW0gr8AiRC/yx8MObXSmYRMoGUP5z0zcL1PAiO4K/CKWpz/TTJH9Epo6EmTKrn4SEYct7FrvZSLF3+wjH/Go3GRQ== X-OriginatorOrg: cipunited.com X-MS-Exchange-CrossTenant-Network-Message-Id: a0e699a3-2199-4d7c-2d38-08db05c5dee9 X-MS-Exchange-CrossTenant-AuthSource: TYZPR04MB6117.apcprd04.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Feb 2023 09:06:01.2857 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e31cf5b5-ee69-4d5f-9c69-edeeda2458c0 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: sogU+bVA2crroFW+obNrm2W7qbomZIx8a/oAN2jyicd0Nouv0Xhql6fDnKTr45HsKNSoxBinf/8JdcAAmb1GMF96U4+/VuvxM/4yvMdPkb8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: KL1PR04MB6758 X-Spam-Status: No, score=-13.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, 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 X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> Errors-To: gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+patchwork=sourceware.org@gcc.gnu.org> |
Series |
MIPS: use arch_32/64 instead of default_mips_arch
|
|
Commit Message
YunQiang Su
Feb. 3, 2023, 9:05 a.m. UTC
The value of default_mips_arch will be always used for -march by default, 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) So we use with_arch_32 and with_arch_64 instead of default_mips_arch for all mipsisa[32,64]rN triples. 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(-)
Comments
YunQiang Su <yunqiang.su@cipunited.com> writes: > The value of default_mips_arch will be always used for -march by default, > 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. > 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. 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. 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="${extra_options} linux-android.opt" > case ${target} in > mipsisa32r6*) > - default_mips_arch=mips32r6 > + with_arch_32="mips32r6" > + with_arch_64="mips64r6" > ;; > mipsisa32r2*) > - default_mips_arch=mips32r2 > + with_arch_32="mips32r2" > + with_arch_64="mips64r2" > ;; > mipsisa32*) > - default_mips_arch=mips32 > + with_arch_32="mips32" > + with_arch_64="mips64" > ;; > mips64el-st-linux-gnu) > default_mips_abi=n32 > @@ -2540,22 +2543,26 @@ mips*-*-linux*) # Linux MIPS, either endian. > ;; > mipsisa64r6*-*-linux-gnuabi64) > default_mips_abi=64 > - default_mips_arch=mips64r6 > + with_arch_32="mips32r6" > + with_arch_64="mips64r6" > enable_mips_multilibs="yes" > ;; > mipsisa64r6*-*-linux*) > default_mips_abi=n32 > - default_mips_arch=mips64r6 > + with_arch_32="mips32r6" > + with_arch_64="mips64r6" > enable_mips_multilibs="yes" > ;; > mipsisa64r2*-*-linux-gnuabi64) > default_mips_abi=64 > - default_mips_arch=mips64r2 > + with_arch_32="mips32r2" > + with_arch_64="mips64r2" > enable_mips_multilibs="yes" > ;; > mipsisa64r2*-*-linux*) > default_mips_abi=n32 > - default_mips_arch=mips64r2 > + with_arch_32="mips32r2" > + with_arch_64="mips64r2" > enable_mips_multilibs="yes" > ;; > mips64*-*-linux-gnuabi64 | mipsisa64*-*-linux-gnuabi64)
Richard Sandiford via Gcc-patches <gcc-patches@gcc.gnu.org> 于2023年2月3日周五 20:29写道: > > YunQiang Su <yunqiang.su@cipunited.com> writes: > > The value of default_mips_arch will be always used for -march by default, > > 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=64 only. $ mipsel-linux-gnu-gcc -mabi=64 -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=32 -march=mips64r2 -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=haswell -c -O3 xx.c && file xx.o xx.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped But MIPS does like: $ mipsel-linux-gnu-gcc -mabi=32 -march=octeon -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=32 -march=mips64r2 -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="${extra_options} linux-android.opt" > > case ${target} in > > mipsisa32r6*) > > - default_mips_arch=mips32r6 > > + with_arch_32="mips32r6" > > + with_arch_64="mips64r6" > > ;; > > mipsisa32r2*) > > - default_mips_arch=mips32r2 > > + with_arch_32="mips32r2" > > + with_arch_64="mips64r2" > > ;; > > mipsisa32*) > > - default_mips_arch=mips32 > > + with_arch_32="mips32" > > + with_arch_64="mips64" > > ;; > > mips64el-st-linux-gnu) > > default_mips_abi=n32 > > @@ -2540,22 +2543,26 @@ mips*-*-linux*) # Linux MIPS, either endian. > > ;; > > mipsisa64r6*-*-linux-gnuabi64) > > default_mips_abi=64 > > - default_mips_arch=mips64r6 > > + with_arch_32="mips32r6" > > + with_arch_64="mips64r6" > > enable_mips_multilibs="yes" > > ;; > > mipsisa64r6*-*-linux*) > > default_mips_abi=n32 > > - default_mips_arch=mips64r6 > > + with_arch_32="mips32r6" > > + with_arch_64="mips64r6" > > enable_mips_multilibs="yes" > > ;; > > mipsisa64r2*-*-linux-gnuabi64) > > default_mips_abi=64 > > - default_mips_arch=mips64r2 > > + with_arch_32="mips32r2" > > + with_arch_64="mips64r2" > > enable_mips_multilibs="yes" > > ;; > > mipsisa64r2*-*-linux*) > > default_mips_abi=n32 > > - default_mips_arch=mips64r2 > > + with_arch_32="mips32r2" > > + with_arch_64="mips64r2" > > enable_mips_multilibs="yes" > > ;; > > mips64*-*-linux-gnuabi64 | mipsisa64*-*-linux-gnuabi64)
YunQiang Su <syq@debian.org> writes: > Richard Sandiford via Gcc-patches <gcc-patches@gcc.gnu.org> > 于2023年2月3日周五 20:29写道: >> >> YunQiang Su <yunqiang.su@cipunited.com> writes: >> > The value of default_mips_arch will be always used for -march by default, >> > 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=64 only. > > $ mipsel-linux-gnu-gcc -mabi=64 -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=32 -march=mips64r2 -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=haswell -c -O3 xx.c && file xx.o > xx.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not stripped > > But MIPS does like: > $ mipsel-linux-gnu-gcc -mabi=32 -march=octeon -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=32 -march=mips64r2 -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=octeon and -march=mips64r2 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="${extra_options} linux-android.opt" >> > case ${target} in >> > mipsisa32r6*) >> > - default_mips_arch=mips32r6 >> > + with_arch_32="mips32r6" >> > + with_arch_64="mips64r6" >> > ;; >> > mipsisa32r2*) >> > - default_mips_arch=mips32r2 >> > + with_arch_32="mips32r2" >> > + with_arch_64="mips64r2" >> > ;; >> > mipsisa32*) >> > - default_mips_arch=mips32 >> > + with_arch_32="mips32" >> > + with_arch_64="mips64" >> > ;; >> > mips64el-st-linux-gnu) >> > default_mips_abi=n32 >> > @@ -2540,22 +2543,26 @@ mips*-*-linux*) # Linux MIPS, either endian. >> > ;; >> > mipsisa64r6*-*-linux-gnuabi64) >> > default_mips_abi=64 >> > - default_mips_arch=mips64r6 >> > + with_arch_32="mips32r6" >> > + with_arch_64="mips64r6" >> > enable_mips_multilibs="yes" >> > ;; >> > mipsisa64r6*-*-linux*) >> > default_mips_abi=n32 >> > - default_mips_arch=mips64r6 >> > + with_arch_32="mips32r6" >> > + with_arch_64="mips64r6" >> > enable_mips_multilibs="yes" >> > ;; >> > mipsisa64r2*-*-linux-gnuabi64) >> > default_mips_abi=64 >> > - default_mips_arch=mips64r2 >> > + with_arch_32="mips32r2" >> > + with_arch_64="mips64r2" >> > enable_mips_multilibs="yes" >> > ;; >> > mipsisa64r2*-*-linux*) >> > default_mips_abi=n32 >> > - default_mips_arch=mips64r2 >> > + with_arch_32="mips32r2" >> > + with_arch_64="mips64r2" >> > enable_mips_multilibs="yes" >> > ;; >> > mips64*-*-linux-gnuabi64 | mipsisa64*-*-linux-gnuabi64)
On Fri, 2023-02-03 at 14:08 +0000, Richard Sandiford via Gcc-patches wrote: > > 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? On gcc230: xry111@gcc230:~$ cat a.c int a() { return 42; } xry111@gcc230:~$ cat b.c extern int a(void); int main() { return a() ^ 42; } xry111@gcc230:~$ cc a.c -mabi=32 -march=mips32r2 -c xry111@gcc230:~$ cc b.c -mabi=32 -march=mips64r2 -c xry111@gcc230:~$ cc a.o b.o xry111@gcc230:~$ ./a.out && echo ok ok xry111@gcc230:~$ xry111@gcc230:~$ ld -version GNU ld (GNU Binutils for Debian) 2.31.1 Copyright (C) 2018 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later version. This program has absolutely no warranty. So I'd consider the issue a GNU ld regression if it suddenly stops to behave like this.
Xi Ruoyao via Gcc-patches <gcc-patches@gcc.gnu.org> 于2023年2月3日周五 22:35写道: > > On Fri, 2023-02-03 at 14:08 +0000, Richard Sandiford via Gcc-patches > wrote: > > > 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? > > On gcc230: > > xry111@gcc230:~$ cat a.c > int a() { return 42; } > xry111@gcc230:~$ cat b.c > extern int a(void); > int main() { return a() ^ 42; } > xry111@gcc230:~$ cc a.c -mabi=32 -march=mips32r2 -c > xry111@gcc230:~$ cc b.c -mabi=32 -march=mips64r2 -c > xry111@gcc230:~$ cc a.o b.o > xry111@gcc230:~$ ./a.out && echo ok > ok > xry111@gcc230:~$ > xry111@gcc230:~$ ld -version > GNU ld (GNU Binutils for Debian) 2.31.1 > Copyright (C) 2018 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or (at your option) a later version. > This program has absolutely no warranty. > > So I'd consider the issue a GNU ld regression if it suddenly stops to > behave like this. Sorry, I made a mistake: r2 works well while r6 does not. root@bookworm-mips64r6el:~# gcc -mabi=32 -mips64r6 -O3 -c yy.c root@bookworm-mips64r6el:~# gcc -mabi=32 -mips32r6 -O3 -c xx.c root@bookworm-mips64r6el:~# gcc -shared -o xx.so yy.o xx.o /usr/bin/ld: yy.o: ABI is incompatible with that of the selected emulation /usr/bin/ld: failed to merge target specific data of file yy.o /usr/bin/ld: xx.o: ABI is incompatible with that of the selected emulation /usr/bin/ld: failed to merge target specific data of file xx.o collect2: error: ld returned 1 exit status So, it seems that I need to find what happens in gnu ld for r6. > -- > Xi Ruoyao <xry111@xry111.site> > School of Aerospace Science and Technology, Xidian University
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="${extra_options} linux-android.opt" case ${target} in mipsisa32r6*) - default_mips_arch=mips32r6 + with_arch_32="mips32r6" + with_arch_64="mips64r6" ;; mipsisa32r2*) - default_mips_arch=mips32r2 + with_arch_32="mips32r2" + with_arch_64="mips64r2" ;; mipsisa32*) - default_mips_arch=mips32 + with_arch_32="mips32" + with_arch_64="mips64" ;; mips64el-st-linux-gnu) default_mips_abi=n32 @@ -2540,22 +2543,26 @@ mips*-*-linux*) # Linux MIPS, either endian. ;; mipsisa64r6*-*-linux-gnuabi64) default_mips_abi=64 - default_mips_arch=mips64r6 + with_arch_32="mips32r6" + with_arch_64="mips64r6" enable_mips_multilibs="yes" ;; mipsisa64r6*-*-linux*) default_mips_abi=n32 - default_mips_arch=mips64r6 + with_arch_32="mips32r6" + with_arch_64="mips64r6" enable_mips_multilibs="yes" ;; mipsisa64r2*-*-linux-gnuabi64) default_mips_abi=64 - default_mips_arch=mips64r2 + with_arch_32="mips32r2" + with_arch_64="mips64r2" enable_mips_multilibs="yes" ;; mipsisa64r2*-*-linux*) default_mips_abi=n32 - default_mips_arch=mips64r2 + with_arch_32="mips32r2" + with_arch_64="mips64r2" enable_mips_multilibs="yes" ;; mips64*-*-linux-gnuabi64 | mipsisa64*-*-linux-gnuabi64)