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 C4D7D3858D1E for ; Mon, 13 Feb 2023 15:47:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C4D7D3858D1E 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 F3F144B3; Mon, 13 Feb 2023 07:48:09 -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 73FB33F703; Mon, 13 Feb 2023 07:47:26 -0800 (PST) From: Richard Sandiford To: YunQiang Su Mail-Followup-To: YunQiang Su ,binutils@sourceware.org, syq@debian.org, macro@orcam.me.uk, xry111@xry111.site, jiaxun.yang@flygoat.com, richard.sandiford@arm.com Cc: binutils@sourceware.org, syq@debian.org, macro@orcam.me.uk, xry111@xry111.site, jiaxun.yang@flygoat.com Subject: Re: [PATCH] MIPS: allow link o32 objects with mach mips64r6 and mips32r6 References: <20230207024424.4000862-1-yunqiang.su@cipunited.com> Date: Mon, 13 Feb 2023 15:47:25 +0000 In-Reply-To: <20230207024424.4000862-1-yunqiang.su@cipunited.com> (YunQiang Su's message of "Tue, 7 Feb 2023 10:44:24 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-34.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,KAM_NUMSUBJECT,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: Sorry for the slow reply. YunQiang Su writes: > The `-32 -mips32r6` and `-32 mips64r6` option of gnu as > will generate objects with different mach attributes. > > 0x90001407, noreorder, pic, cpic, nan2008, o32, mips32r6 > vs > 0xa0001507, noreorder, pic, cpic, 32bitmode, nan2008, o32, mips64r6 > > Let's allow link them togather, just like we did for r2 ones. > > bfd/ChangeLog: > > * elfxx-mips.c (mips_mach_extends_p): allow link o32 objects > with mach mips64r6 and mips32r6. Looks good, but how about making this more systematic by applying it to all mipsisa32 revisions? E.g. have a second array of mips_mach_extension objects that gives the mipsisa32 base and corresponding mipsisa64 "extension" (ok, maybe not really an accurate term in this case, but good enough). Thanks, Richard > --- > bfd/elfxx-mips.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/bfd/elfxx-mips.c b/bfd/elfxx-mips.c > index e9fb61ff9e7..1790b78e822 100644 > --- a/bfd/elfxx-mips.c > +++ b/bfd/elfxx-mips.c > @@ -14600,6 +14600,10 @@ mips_mach_extends_p (unsigned long base, unsigned long extension) > && mips_mach_extends_p (bfd_mach_mipsisa64r2, extension)) > return true; > > + if (base == bfd_mach_mipsisa32r6 > + && mips_mach_extends_p (bfd_mach_mipsisa64r6, extension)) > + return true; > + > for (i = 0; i < ARRAY_SIZE (mips_mach_extensions); i++) > if (extension == mips_mach_extensions[i].extension) > {