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 242153857351 for ; Wed, 9 Aug 2023 17:08:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 242153857351 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 37C01D75; Wed, 9 Aug 2023 10:09:20 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.110.72]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 27D8C3F59C; Wed, 9 Aug 2023 10:08:37 -0700 (PDT) From: Richard Sandiford To: "Maciej W. Rozycki" Mail-Followup-To: "Maciej W. Rozycki" ,Florian Weimer , Ying Huang , libc-alpha , yunqiang.su@oss.cipunited.com, richard.sandiford@arm.com Cc: Florian Weimer , Ying Huang , libc-alpha , yunqiang.su@oss.cipunited.com Subject: Re: [PATCH v7] MIPS: Sync elf.h from binutils References: <20230807020524.2031213-1-ying.huang@oss.cipunited.com> <87leemerwd.fsf@oldenburg.str.redhat.com> <4d3d1518-364c-8374-9d3d-86d1afe25d62@oss.cipunited.com> <87r0odeust.fsf@oldenburg.str.redhat.com> <3d7f6d51-7d7f-cc7c-31b9-744dc06010fa@oss.cipunited.com> <87cyzxfugb.fsf@oldenburg.str.redhat.com> Date: Wed, 09 Aug 2023 18:08:35 +0100 In-Reply-To: (Maciej W. Rozycki's message of "Wed, 9 Aug 2023 17:20:12 +0100 (BST)") 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=-20.0 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no 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" writes: > Florian, Richard -- > >> >>> /I think all new additions are supposed to start with EF_ rather tha= n E_. >> IIUC the existence of E_ >> >>> macros has something to do with the old SVR4 ABI registry maintained= by SCO >> long ago: you >> > could=20 >> >>> only add new EF_ macros once they've been registered with SCO (someo= ne >> please correct me >> > if I'm=20 >> >>> wrong). Also I think the new comments will best be spelt MIPS32r6/MI= PS64r6 >> rather than=20 >> >>> -mips32r6/-mips64r6 for consistency with MIPS32r2/MIPS64r2 above. /= =20 >> >>> After this advice, I changed E_ to EF_ and change the related commen= ts.=20 >> >> Are there plans to change binutils to use the EF_* constants? Having= =20 >> >> separate forms is confusing, especially what =E2=80=9Csyncing=E2=80= =9D means if things=20 >> >> are not in sync after the fact.=20 >> > >> > No, we did not have this plan to change binutils.=20 >> > >> > So should I change these EF_* to original E_*?=20 >>=20 >> Please ask the person who requested EF_*. I think consistency with the >> binutils usage is desirable. > > Florian: this must have been me. > > Please note that binutils use E_* notation exclusively for architectures= =20 > and machines (within the respective masks), however we have both E_* and= =20 > EF_* ones already along with these comments: > > /* Legal values for MIPS architecture level. */ > > #define EF_MIPS_ARCH_1 0x00000000 /* -mips1 code. */ > [...] > > /* The following are unofficial names and should not be used. */ > > #define E_MIPS_ARCH_1 EF_MIPS_ARCH_1 > > so I find it kind of difficult: to stay consistent, not to break backward= s=20 > compatibility, and not to add more "unofficial names" that "should not be= =20 > used", all at a time. > > The EF_* definitions were added on top of preexisting E_* macros back in= =20 > 1998 by Ulrich Drepper with commit c3966b88eeb ("Update.") and only this: > > * elf/elf.h: Add lots of new symbols from Irix and Solaris. > > ChangeLog entry, so it's not exactly easy to figure out the rationale, bu= t=20 > I take it we've been supposed to use the EF_* ones and possibly not to ad= d=20 > new E_* ones. > > This is also why I asked for a second opinion as quoted above. > > Richard: you used to be an IRIX expert, would you mind to chime in if you > have anything to add regarding the use of E_MIPS_* vs EF_MIPS_* macros fo= r=20 > ELF file header flags access? Sorry, I can't remember now. It's probably 20 years since I last used an IRIX box :) Thanks, Richard