* Re: [PATCH v7] MIPS: Sync elf.h from binutils
[not found] ` <87il9oywuh.fsf@oldenburg.str.redhat.com>
@ 2023-08-11 17:43 ` Maciej W. Rozycki
2023-08-16 6:15 ` Ying Huang
2023-08-18 10:10 ` 黄莺
0 siblings, 2 replies; 6+ messages in thread
From: Maciej W. Rozycki @ 2023-08-11 17:43 UTC (permalink / raw)
To: Florian Weimer
Cc: Richard Sandiford, Ying Huang, libc-alpha, yunqiang.su, binutils
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v7] MIPS: Sync elf.h from binutils
2023-08-11 17:43 ` [PATCH v7] MIPS: Sync elf.h from binutils Maciej W. Rozycki
@ 2023-08-16 6:15 ` Ying Huang
2023-08-18 10:10 ` 黄莺
1 sibling, 0 replies; 6+ messages in thread
From: Ying Huang @ 2023-08-16 6:15 UTC (permalink / raw)
To: Maciej W. Rozycki, Florian Weimer
Cc: Richard Sandiford, libc-alpha, yunqiang.su, binutils
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v7] MIPS: Sync elf.h from binutils
2023-08-11 17:43 ` [PATCH v7] MIPS: Sync elf.h from binutils Maciej W. Rozycki
2023-08-16 6:15 ` Ying Huang
@ 2023-08-18 10:10 ` 黄莺
2023-08-21 6:27 ` Ying Huang
1 sibling, 1 reply; 6+ messages in thread
From: 黄莺 @ 2023-08-18 10:10 UTC (permalink / raw)
To: Maciej W. Rozycki, libc-alpha; +Cc: yunqiang.su, 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v7] MIPS: Sync elf.h from binutils
2023-08-18 10:10 ` 黄莺
@ 2023-08-21 6:27 ` Ying Huang
2023-08-21 11:14 ` Maciej W. Rozycki
0 siblings, 1 reply; 6+ messages in thread
From: Ying Huang @ 2023-08-21 6:27 UTC (permalink / raw)
To: Maciej W. Rozycki, libc-alpha; +Cc: yunqiang.su, binutils
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v7] MIPS: Sync elf.h from binutils
2023-08-21 6:27 ` Ying Huang
@ 2023-08-21 11:14 ` Maciej W. Rozycki
2023-08-22 8:55 ` Ying Huang
0 siblings, 1 reply; 6+ messages in thread
From: Maciej W. Rozycki @ 2023-08-21 11:14 UTC (permalink / raw)
To: Ying Huang; +Cc: libc-alpha, yunqiang.su, binutils
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH v7] MIPS: Sync elf.h from binutils
2023-08-21 11:14 ` Maciej W. Rozycki
@ 2023-08-22 8:55 ` Ying Huang
0 siblings, 0 replies; 6+ messages in thread
From: Ying Huang @ 2023-08-22 8:55 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: libc-alpha, yunqiang.su, binutils
[-- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-08-22 8:55 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20230807020524.2031213-1-ying.huang@oss.cipunited.com>
[not found] ` <87leemerwd.fsf@oldenburg.str.redhat.com>
[not found] ` <4d3d1518-364c-8374-9d3d-86d1afe25d62@oss.cipunited.com>
[not found] ` <87r0odeust.fsf@oldenburg.str.redhat.com>
[not found] ` <3d7f6d51-7d7f-cc7c-31b9-744dc06010fa@oss.cipunited.com>
[not found] ` <87cyzxfugb.fsf@oldenburg.str.redhat.com>
[not found] ` <alpine.DEB.2.21.2308091654110.25915@angie.orcam.me.uk>
[not found] ` <87il9oywuh.fsf@oldenburg.str.redhat.com>
2023-08-11 17:43 ` [PATCH v7] MIPS: Sync elf.h from binutils 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
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).