[PATCH v7] MIPS: Sync elf.h from binutils

[PATCH v7] MIPS: Sync elf.h from binutils

[Ying Huang]

[-- Attachment #1: Type: text/plain, Size: 7425 bytes --]

From: Ying Huang <ying.huang@oss.cipunited.com>

Add new definitions for the MIPS target, specifically: relocation
types, machine flags, section type names, and object attribute tags
and values.  On MIPS64, up to three relocations may be specified
within r_info, by the r_type, r_type2, and r_type3 fields, so add new
macros to get the respective reloc types for MIPS64.
---
 elf/elf.h | 137 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 134 insertions(+), 3 deletions(-)

diff --git a/elf/elf.h b/elf/elf.h
index 89fc8021e9..070f70b7db 100644
--- a/elf/elf.h
+++ b/elf/elf.h
@@ -1685,11 +1685,25 @@ typedef struct
 #define EF_MIPS_PIC		2     /* Contains PIC code.  */
 #define EF_MIPS_CPIC		4     /* Uses PIC calling sequence.  */
 #define EF_MIPS_XGOT		8
-#define EF_MIPS_64BIT_WHIRL	16
+#define EF_MIPS_UCODE		16
 #define EF_MIPS_ABI2		32
 #define EF_MIPS_ABI_ON32	64
+#define EF_MIPS_OPTIONS_FIRST	0x00000080 /* Process the .MIPS.options
+					      section first by ld.  */
+#define EF_MIPS_32BITMODE	0x00000100 /* Indicates code compiled for
+					      a 64-bit machine in 32-bit
+					      mode (regs are 32-bits
+					      wide).  */
 #define EF_MIPS_FP64		512  /* Uses FP64 (12 callee-saved).  */
 #define EF_MIPS_NAN2008	1024  /* Uses IEEE 754-2008 NaN encoding.  */
+#define EF_MIPS_ARCH_ASE	0x0f000000 /* Architectural Extensions
+					      used by this file.  */
+#define EF_MIPS_ARCH_ASE_MDMX	0x08000000 /* Use MDMX multimedia
+					      extensions.  */
+#define EF_MIPS_ARCH_ASE_M16	0x04000000 /* Use MIPS-16 ISA
+					      extensions.  */
+#define EF_MIPS_ARCH_ASE_MICROMIPS	0x02000000 /* Use MICROMIPS ISA
+						      extensions.  */
 #define EF_MIPS_ARCH		0xf0000000 /* MIPS architecture level.  */
 
 /* Legal values for MIPS architecture level.  */
@@ -1703,6 +1717,37 @@ typedef struct
 #define EF_MIPS_ARCH_64		0x60000000 /* MIPS64 code.  */
 #define EF_MIPS_ARCH_32R2	0x70000000 /* MIPS32r2 code.  */
 #define EF_MIPS_ARCH_64R2	0x80000000 /* MIPS64r2 code.  */
+#define EF_MIPS_ARCH_32R6	0x90000000 /* MIPS32r6 code.  */
+#define EF_MIPS_ARCH_64R6	0xa0000000 /* MIPS64r6 code.  */
+#define EF_MIPS_ABI		0x0000F000 /* The ABI of the file.  Also
+					      see EF_MIPS_ABI2 above.  */
+#define EF_MIPS_ABI_O32		0x00001000 /* The original o32 abi.  */
+#define EF_MIPS_ABI_O64		0x00002000 /* O32 extended to work on
+					      64 bit architectures.  */
+#define EF_MIPS_ABI_EABI32	0x00003000 /* EABI in 32 bit mode.  */
+#define EF_MIPS_ABI_EABI64	0x00004000 /* EABI in 64 bit mode.  */
+#define EF_MIPS_MACH		0x00FF0000
+#define EF_MIPS_MACH_3900	0x00810000
+#define EF_MIPS_MACH_4010	0x00820000
+#define EF_MIPS_MACH_4100	0x00830000
+#define EF_MIPS_MACH_4650	0x00850000
+#define EF_MIPS_MACH_4120	0x00870000
+#define EF_MIPS_MACH_4111	0x00880000
+#define EF_MIPS_MACH_SB1	0x008a0000
+#define EF_MIPS_MACH_OCTEON	0x008b0000
+#define EF_MIPS_MACH_XLR	0x008c0000
+#define EF_MIPS_MACH_OCTEON2	0x008d0000
+#define EF_MIPS_MACH_OCTEON3	0x008e0000
+#define EF_MIPS_MACH_5400	0x00910000
+#define EF_MIPS_MACH_5900	0x00920000
+#define EF_MIPS_MACH_IAMR2	0x00930000
+#define EF_MIPS_MACH_5500	0x00980000
+#define EF_MIPS_MACH_9000	0x00990000
+#define EF_MIPS_MACH_LS2E	0x00A00000
+#define EF_MIPS_MACH_LS2F	0x00A10000
+#define EF_MIPS_MACH_GS464	0x00A20000
+#define EF_MIPS_MACH_GS464E	0x00A30000
+#define EF_MIPS_MACH_GS264E	0x00A40000
 
 /* The following are unofficial names and should not be used.  */
 
@@ -1763,6 +1808,7 @@ typedef struct
 #define SHT_MIPS_EH_REGION	0x70000027
 #define SHT_MIPS_XLATE_OLD	0x70000028
 #define SHT_MIPS_PDR_EXCEPTION	0x70000029
+#define SHT_MIPS_ABIFLAGS	0x7000002a
 #define SHT_MIPS_XHASH		0x7000002b
 
 /* Legal values for sh_flags field of Elf32_Shdr.  */
@@ -1931,10 +1977,68 @@ typedef struct
 #define R_MIPS_TLS_TPREL_HI16	49	/* TP-relative offset, high 16 bits */
 #define R_MIPS_TLS_TPREL_LO16	50	/* TP-relative offset, low 16 bits */
 #define R_MIPS_GLOB_DAT		51
+#define R_MIPS_PC21_S2		60
+#define R_MIPS_PC26_S2		61
+#define R_MIPS_PC18_S3		62
+#define R_MIPS_PC19_S2		63
+#define R_MIPS_PCHI16		64
+#define R_MIPS_PCLO16		65
+#define R_MIPS16_26		100
+#define R_MIPS16_GPREL		101
+#define R_MIPS16_GOT16		102
+#define R_MIPS16_CALL16		103
+#define R_MIPS16_HI16		104
+#define R_MIPS16_LO16		105
+#define R_MIPS16_TLS_GD		106
+#define R_MIPS16_TLS_LDM	107
+#define R_MIPS16_TLS_DTPREL_HI16	108
+#define R_MIPS16_TLS_DTPREL_LO16	109
+#define R_MIPS16_TLS_GOTTPREL	110
+#define R_MIPS16_TLS_TPREL_HI16	111
+#define R_MIPS16_TLS_TPREL_LO16	112
+#define R_MIPS16_PC16_S1	113
 #define R_MIPS_COPY		126
 #define R_MIPS_JUMP_SLOT        127
+#define R_MIPS_RELATIVE		128
+#define R_MICROMIPS_26_S1	133
+#define R_MICROMIPS_HI16	134
+#define R_MICROMIPS_LO16	135
+#define R_MICROMIPS_GPREL16	136
+#define R_MICROMIPS_LITERAL	137
+#define R_MICROMIPS_GOT16	138
+#define R_MICROMIPS_PC7_S1	139
+#define R_MICROMIPS_PC10_S1	140
+#define R_MICROMIPS_PC16_S1	141
+#define R_MICROMIPS_CALL16	142
+#define R_MICROMIPS_GOT_DISP	145
+#define R_MICROMIPS_GOT_PAGE	146
+#define R_MICROMIPS_GOT_OFST	147
+#define R_MICROMIPS_GOT_HI16	148
+#define R_MICROMIPS_GOT_LO16	149
+#define R_MICROMIPS_SUB		150
+#define R_MICROMIPS_HIGHER	151
+#define R_MICROMIPS_HIGHEST	152
+#define R_MICROMIPS_CALL_HI16	153
+#define R_MICROMIPS_CALL_LO16	154
+#define R_MICROMIPS_SCN_DISP	155
+#define R_MICROMIPS_JALR	156
+#define R_MICROMIPS_HI0_LO16	157
+#define R_MICROMIPS_TLS_GD	162
+#define R_MICROMIPS_TLS_LDM	163
+#define R_MICROMIPS_TLS_DTPREL_HI16	164
+#define R_MICROMIPS_TLS_DTPREL_LO16	165
+#define R_MICROMIPS_TLS_GOTTPREL	166
+#define R_MICROMIPS_TLS_TPREL_HI16	169
+#define R_MICROMIPS_TLS_TPREL_LO16	170
+#define R_MICROMIPS_GPREL7_S2	172
+#define R_MICROMIPS_PC23_S2	173
+#define R_MIPS_PC32		248
+#define R_MIPS_EH		249
+#define R_MIPS_GNU_REL16_S2	250
+#define R_MIPS_GNU_VTINHERIT	253
+#define R_MIPS_GNU_VTENTRY	254
 /* Keep this the last entry.  */
-#define R_MIPS_NUM		128
+#define R_MIPS_NUM		255
 
 /* Legal values for p_type field of Elf32_Phdr.  */
 
@@ -2142,6 +2246,30 @@ typedef struct
 /* Masks for the flags1 word of an ABI flags structure.  */
 #define MIPS_AFL_FLAGS1_ODDSPREG  1  /* Uses odd single-precision registers.  */
 
+/* Object attribute tags.  */
+enum
+{
+  /* 0-3 are generic.  */
+
+  /* Floating-point ABI used by this object file.  */
+  Tag_GNU_MIPS_ABI_FP = 4,
+
+  /* MSA ABI used by this object file.  */
+  Tag_GNU_MIPS_ABI_MSA = 8,
+};
+
+/* Object attribute values.  */
+enum
+{
+  /* Values defined for Tag_GNU_MIPS_ABI_MSA.  */
+
+  /* Not tagged or not using any ABIs affected by the differences.  */
+  Val_GNU_MIPS_ABI_MSA_ANY = 0,
+
+  /* Using 128-bit MSA.  */
+  Val_GNU_MIPS_ABI_MSA_128 = 1,
+};
+
 /* Object attribute values.  */
 enum
 {
@@ -2161,8 +2289,11 @@ enum
   Val_GNU_MIPS_ABI_FP_64 = 6,
   /* Using -mips32r2 -mfp64 -mno-odd-spreg.  */
   Val_GNU_MIPS_ABI_FP_64A = 7,
+  /* This is reserved for backward-compatibility with an earlier
+     implementation of the MIPS NaN2008 functionality.  */
+  Val_GNU_MIPS_ABI_FP_NAN2008 = 8,
   /* Maximum allocated FP ABI value.  */
-  Val_GNU_MIPS_ABI_FP_MAX = 7
+  Val_GNU_MIPS_ABI_FP_MAX = 8
 };
 
 /* HPPA specific definitions.  */
-- 
2.30.2

Re: [PATCH v7] MIPS: Sync elf.h from binutils

[Florian Weimer]

* Ying Huang:

> From: Ying Huang <ying.huang@oss.cipunited.com>
>
> Add new definitions for the MIPS target, specifically: relocation
> types, machine flags, section type names, and object attribute tags
> and values.  On MIPS64, up to three relocations may be specified
> within r_info, by the r_type, r_type2, and r_type3 fields, so add new
> macros to get the respective reloc types for MIPS64.

Sorry, it's a bit of a mystery against what exactly you are syncing.
Current binutils has E_MIPS_MACH_ALLEGREX, which you are not adding.  On
the other hand, binutils lacks EF_MIPS_ARCH_32R6, which your patch adds.
(These are just two illustrative examples.)

At least from the glibc side, this now looks okay, it's just about
documenting where the constants come from.

Thanks,
Florian

Re: [PATCH v7] MIPS: Sync elf.h from binutils

[Ying Huang]

[-- Attachment #1: Type: text/plain, Size: 2033 bytes --]

Hi Florian,

在 2023/8/8 00:30, Florian Weimer 写道:
> * Ying Huang:
>
>> From: Ying Huang <ying.huang@oss.cipunited.com>
>>
>> Add new definitions for the MIPS target, specifically: relocation
>> types, machine flags, section type names, and object attribute tags
>> and values.  On MIPS64, up to three relocations may be specified
>> within r_info, by the r_type, r_type2, and r_type3 fields, so add new
>> macros to get the respective reloc types for MIPS64.
> Sorry, it's a bit of a mystery against what exactly you are syncing.
> Current binutils has E_MIPS_MACH_ALLEGREX, which you are not adding.  On
> the other hand, binutils lacks EF_MIPS_ARCH_32R6, which your patch adds.
> (These are just two illustrative examples.)
>
> At least from the glibc side, this now looks okay, it's just about
> documenting where the constants come from.
>
> Thanks,
> Florian


The macro E_MIPS_MACH_ALLEGREX was added at Jun 15 2023, sorry I forgot to confirm whether it update.

I would add and update the commit messange.

See mail: Re: [PATCH v4] MIPS: Sync elf.h from binutils

/在 2023/6/5 01:02, Maciej W. Rozycki 写道:/
//
> /@@ -1703,6 +1713,35 @@ typedef struct #define EF_MIPS_ARCH_64 0x60000000 /* MIPS64 code. */ #define EF_MIPS_ARCH_32R2 0x70000000 /* MIPS32r2 code. */ #define EF_MIPS_ARCH_64R2 0x80000000 /* MIPS64r2 code. */ +#define E_MIPS_ARCH_32R6 0x90000000 /* -mips32r6 code. */ +#define E_MIPS_ARCH_64R6 0xa0000000 /* -mips64r6 code. */ /
//

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

Thanks,
Ying

Re: [PATCH v7] MIPS: Sync elf.h from binutils

[Florian Weimer]

* Ying Huang:

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

(Should we refactor binutils to use an exact copy of <elf.h> from glibc,
in addition to the additional per-architecture headers?)

Thanks,
Florian

Re: [PATCH v7] MIPS: Sync elf.h from binutils

[Ying Huang]

[-- Attachment #1: Type: text/plain, Size: 1095 bytes --]

Hi Florian,

在 2023/8/8 17:40, Florian Weimer 写道:
> * Ying Huang:
>
>> /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_*?

>
> (Should we refactor binutils to use an exact copy of <elf.h> from glibc,
> in addition to the additional per-architecture headers?)
>
> Thanks,
> Florian

Thanks,

Ying

Re: [PATCH v7] MIPS: Sync elf.h from binutils

[Florian Weimer]

* Ying Huang:

> Hi Florian, 
>
> 在 2023/8/8 17:40, Florian Weimer 写道: 
>> * Ying Huang: 
>> 
>>> /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.

Thanks,
Florian

Re: [PATCH v7] MIPS: Sync elf.h from binutils

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

ChangeLog entry, so it's not exactly easy to figure out the rationale, but 
I take it we've been supposed to use the EF_* ones and possibly not to add 
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 for 
ELF file header flags access?

  Maciej

Re: [PATCH v7] MIPS: Sync elf.h from binutils

[Florian Weimer]

* 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

Re: [PATCH v7] MIPS: Sync elf.h from binutils

[Richard Sandiford]

"Maciej W. Rozycki" <macro@orcam.me.uk> writes:
> 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.
>
> ChangeLog entry, so it's not exactly easy to figure out the rationale, but 
> I take it we've been supposed to use the EF_* ones and possibly not to add 
> 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 for 
> 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

Re: [PATCH v7] MIPS: Sync elf.h from binutils

[Maciej W. Rozycki]

Hi Florian,

 Cc-ing binutils now, to get a record of this discussion there.

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

 It's not a problem: as long as we reach consensus I can update binutils 
accordingly, and we can discard E_* constants from there at any time if 
needed as they are for BFD use only and we don't offer any stable BFD API.

> Not sure if this a reasonable position, though.

 So I did a little more research on this topic and came across this thread 
of mine from decades ago, and specifically this message coming from the 
lost world: <https://sourceware.org/ml/binutils/2002-07/msg00681.html>. 
Clearly IRIX used to use EF_* macros, just as I thought and just as has 
used the Linux kernel (and MTI never came to finishing their promised 
psABI spec, where it only says "To be supplied" in the relevant part[1]).

 So while we may have to keep the few already existing in <elf.h>, just 
because we were unfortunate enough to make them a part of our API back in 
1996:

	* elf/elf.h: Add some new constants from recent Cygnus ELF
	header files.

having likely taken them as a Cygnus invention without due consideration, 
I think we ought to refrain from adding new E_* macros and stick to EF_* 
instead.

 NB the whole thread referred above might be worth reviewing for anyone 
interested in these matters.  Here's a reference for the earlier part:
<https://lore.kernel.org/r/Pine.GSO.3.96.1020724182704.27732L-100000@delta.ds2.pg.gda.pl/>
as the discussion started on the old MIPS/Linux mailing lists first and 
then was carried over to binutils as well.

References:

[1] "MIPS ABIs Described", MIPS Technologies, Inc., Document Number: 
    MD00305, Revision 1.3, 2002/12/02, Chapter 7. "ELF object code", p. 24
    <https://web.archive.org/web/20140911162016/https://dmz-portal.mips.com/mw/images/f/fe/MD00305-2B-ABIDESC-SPC-01.03.pdf>

  Maciej

Re: [PATCH v7] MIPS: Sync elf.h from binutils

[Maciej W. Rozycki]

On Wed, 9 Aug 2023, Richard Sandiford wrote:

> >  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 for 
> > ELF file header flags access?
> 
> Sorry, I can't remember now.  It's probably 20 years since I last used
> an IRIX box :)

 No worries, I thought it might be the case, but if you don't ask you'll 
never know.  Anyway I have found an old message from David Anderson of SGI 
now, coincidentally in a discussion thread I have initiated myself, which 
I think makes things clear here.  Thank you for responding anyway.

  Maciej

Re: [PATCH v7] MIPS: Sync elf.h from binutils

[Ying Huang]

[-- Attachment #1: Type: text/plain, Size: 2682 bytes --]

Hi Maciej，

在 2023/8/12 01:43, Maciej W. Rozycki 写道:
> Hi Florian,
>
>  Cc-ing binutils now, to get a record of this discussion there.
>
>>>  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.
>  It's not a problem: as long as we reach consensus I can update binutils 
> accordingly, and we can discard E_* constants from there at any time if 
> needed as they are for BFD use only and we don't offer any stable BFD API.

  Thanks for your detailed investigation.  If we use EF_MIPS_* in glibc and update binutils, the places

where all E_MIPS_* used would also be changed to EF_MIPS_*？


Thanks,

Ying

>> Not sure if this a reasonable position, though.
>  So I did a little more research on this topic and came across this thread 
> of mine from decades ago, and specifically this message coming from the 
> lost world: <https://sourceware.org/ml/binutils/2002-07/msg00681.html>. 
> Clearly IRIX used to use EF_* macros, just as I thought and just as has 
> used the Linux kernel (and MTI never came to finishing their promised 
> psABI spec, where it only says "To be supplied" in the relevant part[1]).
>
>  So while we may have to keep the few already existing in <elf.h>, just 
> because we were unfortunate enough to make them a part of our API back in 
> 1996:
>
> 	* elf/elf.h: Add some new constants from recent Cygnus ELF
> 	header files.
>
> having likely taken them as a Cygnus invention without due consideration, 
> I think we ought to refrain from adding new E_* macros and stick to EF_* 
> instead.
>
>  NB the whole thread referred above might be worth reviewing for anyone 
> interested in these matters.  Here's a reference for the earlier part:
> <https://lore.kernel.org/r/Pine.GSO.3.96.1020724182704.27732L-100000@delta.ds2.pg.gda.pl/>
> as the discussion started on the old MIPS/Linux mailing lists first and 
> then was carried over to binutils as well.
>
> References:
>
> [1] "MIPS ABIs Described", MIPS Technologies, Inc., Document Number: 
>     MD00305, Revision 1.3, 2002/12/02, Chapter 7. "ELF object code", p. 24
>     <https://web.archive.org/web/20140911162016/https://dmz-portal.mips.com/mw/images/f/fe/MD00305-2B-ABIDESC-SPC-01.03.pdf>
>
>   Maciej

Re: [PATCH v7] MIPS: Sync elf.h from binutils

[黄莺]

[-- Attachment #1: Type: text/plain, Size: 2989 bytes --]

Hi Maciej,
I have submitted pacth v10 including changing all E_MIPS_* to EF_MIPS_, and also update binutils & submit patch.
Thanks,
Ying
> From: "Maciej W. Rozycki"<macro@orcam.me.uk>
> Date:  Sat, Aug 12, 2023, 01:43
> Subject:  Re: [PATCH v7] MIPS: Sync elf.h from binutils
> To: "Florian Weimer"<fweimer@redhat.com>
> 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>, <binutils@sourceware.org>
> Hi Florian,
> 
>  Cc-ing binutils now, to get a record of this discussion there.
> 
> > >  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.
> 
>  It's not a problem: as long as we reach consensus I can update binutils 
> accordingly, and we can discard E_* constants from there at any time if 
> needed as they are for BFD use only and we don't offer any stable BFD API.
> 
> > Not sure if this a reasonable position, though.
> 
>  So I did a little more research on this topic and came across this thread 
> of mine from decades ago, and specifically this message coming from the 
> lost world: <https://sourceware.org/ml/binutils/2002-07/msg00681.html>. 
> Clearly IRIX used to use EF_* macros, just as I thought and just as has 
> used the Linux kernel (and MTI never came to finishing their promised 
> psABI spec, where it only says "To be supplied" in the relevant part[1]).
> 
>  So while we may have to keep the few already existing in <elf.h>, just 
> because we were unfortunate enough to make them a part of our API back in 
> 1996:
> 
> 	* elf/elf.h: Add some new constants from recent Cygnus ELF
> 	header files.
> 
> having likely taken them as a Cygnus invention without due consideration, 
> I think we ought to refrain from adding new E_* macros and stick to EF_* 
> instead.
> 
>  NB the whole thread referred above might be worth reviewing for anyone 
> interested in these matters.  Here's a reference for the earlier part:
> <https://lore.kernel.org/r/Pine.GSO.3.96.1020724182704.27732L-100000@delta.ds2.pg.gda.pl/>
> as the discussion started on the old MIPS/Linux mailing lists first and 
> then was carried over to binutils as well.
> 
> References:
> 
> [1] "MIPS ABIs Described", MIPS Technologies, Inc., Document Number: 
>     MD00305, Revision 1.3, 2002/12/02, Chapter 7. "ELF object code", p. 24
>     <https://web.archive.org/web/20140911162016/https://dmz-portal.mips.com/mw/images/f/fe/MD00305-2B-ABIDESC-SPC-01.03.pdf>
> 
>   Maciej

Re: [PATCH v7] MIPS: Sync elf.h from binutils

[Ying Huang]

[-- Attachment #1: Type: text/plain, Size: 2913 bytes --]

Hi Maciej,

Can you help commit  these two patchs?

Thanks,

Ying


在 2023/8/18 18:10, 黄莺 写道:
> Hi Maciej,
> I have submitted pacthv10 including changing all E_MIPS_* to EF_MIPS_, and also updatebinutils & submit patch.
> Thanks,
> Ying
> From: "Maciej W. Rozycki"<macro@orcam.me.uk>
> Date: Sat, Aug 12, 2023, 01:43
> Subject: Re: [PATCH v7] MIPS: Sync elf.h from binutils
> To: "Florian Weimer"<fweimer@redhat.com>
> 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>, <binutils@sourceware.org>
> Hi Florian, Cc-ing binutils now, to get a record of this discussion there. > > 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. It's not a problem: as long as we reach consensus I can update binutils accordingly, and we can discard E_* constants from there at any time if needed as they are for BFD use only and we don't offer any stable BFD API. > Not sure if this a reasonable position, though. So I did a little more research on this topic and came across this thread of mine from decades ago, and specifically this message coming from the lost world:
> <https://sourceware.org/ml/binutils/2002-07/msg00681.html>. Clearly IRIX used to use EF_* macros, just as I thought and just as has used the Linux kernel (and MTI never came to finishing their promised psABI spec, where it only says "To be supplied" in the relevant part[1]). So while we may have to keep the few already existing in <elf.h>, just because we were unfortunate enough to make them a part of our API back in 1996: * elf/elf.h: Add some new constants from recent Cygnus ELF header files. having likely taken them as a Cygnus invention without due consideration, I think we ought to refrain from adding new E_* macros and stick to EF_* instead. NB the whole thread referred above might be worth reviewing for anyone interested in these matters. Here's a reference for the earlier part: <https://lore.kernel.org/r/Pine.GSO.3.96.1020724182704.27732L-100000@delta.ds2.pg.gda.pl/> as the discussion started on the old MIPS/Linux mailing lists first and then was carried over to
> binutils as well. References: [1] "MIPS ABIs Described", MIPS Technologies, Inc., Document Number: MD00305, Revision 1.3, 2002/12/02, Chapter 7. "ELF object code", p. 24 <https://web.archive.org/web/20140911162016/https://dmz-portal.mips.com/mw/images/f/fe/MD00305-2B-ABIDESC-SPC-01.03.pdf> Maciej

Re: [PATCH v7] MIPS: Sync elf.h from binutils

[Maciej W. Rozycki]

On Mon, 21 Aug 2023, Ying Huang wrote:

> Can you help commit  these two patchs?

 To move forward you need to put the findings from the discussion in the 
change description, especially given the difficulty to figure out what the 
correct naming convention for the ELF file header flags is supposed to be.  
This is so that the next time this information is needed it is readily 
available rather than requiring chasing in the archives and/or depending 
on the presence of people who may still remember it as on this occasion.

 I think it will help if you split the glibc patch into self-contained 
functional subsets:

1. File header flags -- need documentation, as noted above.

2. SHT_MIPS_ABIFLAGS section type -- obviously correct, no need to
   elaborate on it.

3. Relocation types -- obviously correct, no need to elaborate on it.

4. GNU attribute stuff -- technically Tag_GNU_MIPS_ABI_FP along with the 
   enumeration it comes with is a bug fix for commit 0bd956720c45 ("Add 
   support for MIPS O32 FPXX and .MIPS.abiflags") which, conservatively, 
   only added definitions actually used by the dynamic loader itself, 
   despite that the header is a part of our public API for the MIPS psABI.  
   I think that either said definitions ought to have been provided 
   internally only or the whole of the API should have been exported at 
   once (this applies to #2 above too).

   Then the MSA stuff and Val_GNU_MIPS_ABI_FP_NAN2008 as later additions 
   are distinct changes each.  I think it is worth mentioning in the 
   inline comment that the latter attribute value has been superseded by 
   EF_MIPS_NAN2008.

   I'd be tempted to say these would best be three distint changes then, 
   but maybe other people would consider it overly pedantic.

 Then the binutils change needs to document the switch from E_* to EF_* 
definitions accordingly.

  Maciej

Re: [PATCH v7] MIPS: Sync elf.h from binutils

[Ying Huang]

[-- Attachment #1: Type: text/plain, Size: 2550 bytes --]

Hi Maciej,

Thanks for your detailed reply, and I have some questions about them.


在 2023/8/21 19:14, Maciej W. Rozycki 写道:
> On Mon, 21 Aug 2023, Ying Huang wrote:
>
>> Can you help commit  these two patchs?
>  To move forward you need to put the findings from the discussion in the 
> change description, especially given the difficulty to figure out what the 
> correct naming convention for the ELF file header flags is supposed to be.  
> This is so that the next time this information is needed it is readily 
> available rather than requiring chasing in the archives and/or depending 
> on the presence of people who may still remember it as on this occasion.
>
>  I think it will help if you split the glibc patch into self-contained 
> functional subsets:
>
> 1. File header flags -- need documentation, as noted above.
>
> 2. SHT_MIPS_ABIFLAGS section type -- obviously correct, no need to
>    elaborate on it.
>
> 3. Relocation types -- obviously correct, no need to elaborate on it.
>
> 4. GNU attribute stuff -- technically Tag_GNU_MIPS_ABI_FP along with the 
>    enumeration it comes with is a bug fix for commit 0bd956720c45 ("Add 
>    support for MIPS O32 FPXX and .MIPS.abiflags") which, conservatively, 
>    only added definitions actually used by the dynamic loader itself, 
>    despite that the header is a part of our public API for the MIPS psABI.  
>    I think that either said definitions ought to have been provided 
>    internally only or the whole of the API should have been exported at 
>    once (this applies to #2 above too).

Sorry, I am not very clear about this #4 above.

What is the whole API?

Did you mean not to submit the GNU attribute part or submit the whole API?

>
>    Then the MSA stuff and Val_GNU_MIPS_ABI_FP_NAN2008 as later additions 
>    are distinct changes each.  I think it is worth mentioning in the 
>    inline comment that the latter attribute value has been superseded by 
>    EF_MIPS_NAN2008.
Only to add comments before enum Val_GNU_MIPS_ABI_FP_NAN2008?
>
>    I'd be tempted to say these would best be three distint changes then, 
>    but maybe other people would consider it overly pedantic.
What are these threee changes?
>
>  Then the binutils change needs to document the switch from E_* to EF_* 
> definitions accordingly.
>
>   Maciej

I have submitted patch to binutils which is https://sourceware.org/pipermail/binutils/2023-August/129098.html.

Did you mean append commit message?


Thanks,

Ying