From: Florian Weimer <fweimer@redhat.com>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Richard Sandiford <richard.sandiford@arm.com>,
Ying Huang <ying.huang@oss.cipunited.com>,
libc-alpha <libc-alpha@sourceware.org>,
yunqiang.su@oss.cipunited.com
Subject: Re: [PATCH v7] MIPS: Sync elf.h from binutils
Date: Wed, 09 Aug 2023 19:00:38 +0200 [thread overview]
Message-ID: <87il9oywuh.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2308091654110.25915@angie.orcam.me.uk> (Maciej W. Rozycki's message of "Wed, 9 Aug 2023 17:20:12 +0100 (BST)")
* Maciej W. Rozycki:
> Florian, Richard --
>
>> >>> /I think all new additions are supposed to start with EF_ rather than E_.
>> IIUC the existence of E_
>> >>> macros has something to do with the old SVR4 ABI registry maintained by SCO
>> long ago: you
>> > could
>> >>> only add new EF_ macros once they've been registered with SCO (someone
>> please correct me
>> > if I'm
>> >>> wrong). Also I think the new comments will best be spelt MIPS32r6/MIPS64r6
>> rather than
>> >>> -mips32r6/-mips64r6 for consistency with MIPS32r2/MIPS64r2 above. /
>> >>> After this advice, I changed E_ to EF_ and change the related comments.
>> >> Are there plans to change binutils to use the EF_* constants? Having
>> >> separate forms is confusing, especially what “syncing” means if things
>> >> are not in sync after the fact.
>> >
>> > No, we did not have this plan to change binutils.
>> >
>> > So should I change these EF_* to original E_*?
>>
>> 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
> and machines (within the respective masks), however we have both E_* and
> 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 backwards
> compatibility, and not to add more "unofficial names" that "should not be
> used", all at a time.
>
> The EF_* definitions were added on top of preexisting E_* macros back in
> 1998 by Ulrich Drepper with commit c3966b88eeb ("Update.") and only this:
>
> * elf/elf.h: Add lots of new symbols from Irix and Solaris.
My concern was adding EF_* constants to glibc that duplicate E_*
constants that are used in binutils. I think we should either change
binutils to use the EF_* constants, too, or for these legacy constants,
use the E_* prefix in glibc as well.
Not sure if this a reasonable position, though.
Thanks,
Florian
next prev parent reply other threads:[~2023-08-09 17:00 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-07 2:05 Ying Huang
2023-08-07 16:30 ` Florian Weimer
2023-08-08 3:36 ` Ying Huang
2023-08-08 9:40 ` Florian Weimer
2023-08-08 10:15 ` Ying Huang
2023-08-08 15:02 ` Florian Weimer
2023-08-09 16:20 ` Maciej W. Rozycki
2023-08-09 17:00 ` Florian Weimer [this message]
2023-08-11 17:43 ` Maciej W. Rozycki
2023-08-16 6:15 ` Ying Huang
2023-08-18 10:10 ` 黄莺
2023-08-21 6:27 ` Ying Huang
2023-08-21 11:14 ` Maciej W. Rozycki
2023-08-22 8:55 ` Ying Huang
2023-08-09 17:08 ` Richard Sandiford
2023-08-11 17:47 ` Maciej W. Rozycki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87il9oywuh.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=macro@orcam.me.uk \
--cc=richard.sandiford@arm.com \
--cc=ying.huang@oss.cipunited.com \
--cc=yunqiang.su@oss.cipunited.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).