public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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


  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).