| Message ID | 20230807020524.2031213-1-ying.huang@oss.cipunited.com |
|---|---|
| State | New |
| Headers | show |
| Series | [v7] MIPS: Sync elf.h from binutils | expand |
* 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
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
* 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
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
* 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
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
* 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
"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
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
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
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
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
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
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
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
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. */
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(-)