* Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE [not found] ` <CAMe9rOr7PVkz1k8dAPXoJjiCjiQ32f26ZduMX6xuxbGzguG=zQ@mail.gmail.com> @ 2020-06-17 16:00 ` Vivek Das Mohapatra 2020-06-17 16:16 ` Michael Matz 0 siblings, 1 reply; 8+ messages in thread From: Vivek Das Mohapatra @ 2020-06-17 16:00 UTC (permalink / raw) To: gnu-gabi Hi - notifying this list (as requested) of a patchset to binutils-gdb, described below: https://sourceware.org/pipermail/binutils/2020-June/111747.html > This patch series is in support of the glibc RTLD_SHARED work > discussed in https://sourceware.org/bugzilla/show_bug.cgi?id=22745. > > It adds a DT_GNU_UNIQUE dynamic section which is intended to mark > libraries which should implicitly be opened as if RTLD_SHARED > had been passed to dlmopen when the target namespace is not > LM_ID_BASE. > > This patch series adds support for DT_GNU_UNIQUE to ld, gold, and > readelf (and documents it in the help text and so forth). ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE 2020-06-17 16:00 ` [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE Vivek Das Mohapatra @ 2020-06-17 16:16 ` Michael Matz 2020-06-17 16:37 ` Vivek Das Mohapatra 0 siblings, 1 reply; 8+ messages in thread From: Michael Matz @ 2020-06-17 16:16 UTC (permalink / raw) To: Vivek Das Mohapatra; +Cc: gnu-gabi Hello, On Wed, 17 Jun 2020, Vivek Das Mohapatra via Gnu-gabi wrote: > Hi - notifying this list (as requested) of a patchset to binutils-gdb, > described below: > > https://sourceware.org/pipermail/binutils/2020-June/111747.html Can you describe the purpose and semantics of the new dynamic tag in textual form that doesn't refer to glibc functions and terms? I.e. something that we can actually discuss on this mailing list? Because the best description in the patch series seems to be what you quoted: > > It adds a DT_GNU_UNIQUE dynamic section which is intended to mark > > libraries which should implicitly be opened as if RTLD_SHARED > > had been passed to dlmopen when the target namespace is not > > LM_ID_BASE. and that doesn't seem to be text we want to put into the GNU variant of the gABI, e.g. it talks about namespaces (no gABI concept) and dlmopen (also no gABI function). I mean, we could just reserve value 0x6ffffdf4 with name DT_GNU_UNIQUE in the GNU/Linux gABI and be done. But it seems saner to actually document the intended semantics of it at the same place where it's reserved. Ciao, Michael. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE 2020-06-17 16:16 ` Michael Matz @ 2020-06-17 16:37 ` Vivek Das Mohapatra 2020-06-17 18:23 ` Cary Coutant 0 siblings, 1 reply; 8+ messages in thread From: Vivek Das Mohapatra @ 2020-06-17 16:37 UTC (permalink / raw) To: Michael Matz; +Cc: gnu-gabi On Wed, 17 Jun 2020, Michael Matz wrote: > Can you describe the purpose and semantics of the new dynamic tag in > textual form that doesn't refer to glibc functions and terms? I.e. > something that we can actually discuss on this mailing list? I can give it a shot, sure: The tricky part is that it really isn't necessary when you don't have namespaced DSO loading. But let's see if I can come up with something sensible. > I mean, we could just reserve value 0x6ffffdf4 with name DT_GNU_UNIQUE in > the GNU/Linux gABI and be done. But it seems saner to actually document > the intended semantics of it at the same place where it's reserved. That seems entirely reasonable. ------------------------------------------------------------------------- I should open by saying I originally implemented this as a new bitfield value for the payload of DT_FLAGS_1, but was told a new DT_GNU_… section might be more palatable/portable/less-conflict-prone. I have no axe to grind either way, both approaches work well for me. ------------------------------------------------------------------------- That said: The purpose of this tag is to mark DSOs which must be loaded no more than once by the dynamic loader. In normal use this is never a problem as the link chain is a simple linked list but when a partitioned loading scheme (such as the extra namespaces available via dlmopen(3) in glibc) is present it is possible for multiple copies of the same DSO to be resident. For DSOs which are "fundamental" in some way (eg libc.so, libpthread.so) the presence of a second copy can cause bizarre and difficult to debug problems. This tag hints to the linker/loader that the DSO should be present at most once, and requests (implicit or explicit) to load a segregated copy of it should NOT be honoured. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE 2020-06-17 16:37 ` Vivek Das Mohapatra @ 2020-06-17 18:23 ` Cary Coutant 2020-06-17 19:13 ` Vivek Das Mohapatra 0 siblings, 1 reply; 8+ messages in thread From: Cary Coutant @ 2020-06-17 18:23 UTC (permalink / raw) To: Vivek Das Mohapatra; +Cc: Michael Matz, gnu-gabi > I should open by saying I originally implemented this as a new bitfield > value for the payload of DT_FLAGS_1, but was told a new DT_GNU_… section > might be more palatable/portable/less-conflict-prone. I don't know why you were advised that, but it seems to me that using DT_FLAGS_1 is the right approach. Dynamic table tags are meant to convey a value other than a simple boolean; if all you need is a flag, well, that's what DT_FLAGS and DT_FLAGS_1 are for. For precedent, note that the old dynamic table entries DT_SYMBOLIC, DT_TEXTREL, and DT_BIND_NOW have all been replaced by flags in DT_FLAGS. DT_FLAGS_1 is a Gnu extension, so it's the place for a Gnu-specific flag. Perhaps the concern was that DT_FLAGS_1 is also used by Solaris, so I suppose you'd want to get agreement from them to use one of those bits. You could always add a DT_GNU_FLAGS if DT_FLAGS_1 isn't acceptable. -cary ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE 2020-06-17 18:23 ` Cary Coutant @ 2020-06-17 19:13 ` Vivek Das Mohapatra 2020-06-26 15:12 ` [RFC][PATCH v3 0/6] binutils patches to add DF_1_UNIQUE Vivek Das Mohapatra 0 siblings, 1 reply; 8+ messages in thread From: Vivek Das Mohapatra @ 2020-06-17 19:13 UTC (permalink / raw) To: Cary Coutant; +Cc: Michael Matz, gnu-gabi > DT_FLAGS_1 is a Gnu extension, so it's the place for a Gnu-specific > flag. Perhaps the concern was that DT_FLAGS_1 is also used by Solaris, > so I suppose you'd want to get agreement from them to use one of those I'm happy to submit the DT_FLAGS_1 version of the patchset here. Any idea where I'd have to seek out Solaris people to get agreement, or at least acquiescence? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC][PATCH v3 0/6] binutils patches to add DF_1_UNIQUE 2020-06-17 19:13 ` Vivek Das Mohapatra @ 2020-06-26 15:12 ` Vivek Das Mohapatra 2020-06-26 15:29 ` H.J. Lu 0 siblings, 1 reply; 8+ messages in thread From: Vivek Das Mohapatra @ 2020-06-26 15:12 UTC (permalink / raw) To: Cary Coutant; +Cc: gnu-gabi I have submitted an updated patch series to the binutils list. DSOs are now tagged with a DT_FLAGS_1 value: DF_1_UNIQUE instead of a new dynamic section. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [RFC][PATCH v3 0/6] binutils patches to add DF_1_UNIQUE 2020-06-26 15:12 ` [RFC][PATCH v3 0/6] binutils patches to add DF_1_UNIQUE Vivek Das Mohapatra @ 2020-06-26 15:29 ` H.J. Lu [not found] ` <ca72c789-f60c-2eaf-18e9-a7e59fcb0319@Oracle.COM> 0 siblings, 1 reply; 8+ messages in thread From: H.J. Lu @ 2020-06-26 15:29 UTC (permalink / raw) To: Vivek Das Mohapatra, Generic System V Application Binary Interface Cc: Cary Coutant, Rahul Chaudhry via gnu-gabi On Fri, Jun 26, 2020 at 8:12 AM Vivek Das Mohapatra via Gnu-gabi <gnu-gabi@sourceware.org> wrote: > > I have submitted an updated patch series to the binutils list. > > DSOs are now tagged with a DT_FLAGS_1 value: DF_1_UNIQUE > instead of a new dynamic section. > CC gABI: https://sourceware.org/pipermail/binutils/2020-June/111925.html Please create a merge request at https://gitlab.com/x86-psABIs/Linux-ABI to document DF_1_UNIQUE. Thanks. -- H.J. ^ permalink raw reply [flat|nested] 8+ messages in thread
[parent not found: <ca72c789-f60c-2eaf-18e9-a7e59fcb0319@Oracle.COM>]
[parent not found: <CAMe9rOqF-zUUsCeyiT8s20bhTeVhozZtGkAD-JRrNiEOaju7jQ@mail.gmail.com>]
[parent not found: <8af0af5a-9fd4-2e80-1dff-ff714a15a6b2@Oracle.COM>]
[parent not found: <20200626173513.22arn2ihwgxudmjf@google.com>]
[parent not found: <CAMe9rOorOgV6wT3gHVdfK-zKp11kUVcqtBZHSSd__EdQtWvcKw@mail.gmail.com>]
* Re: [RFC][PATCH v3 0/6] binutils patches to add DF_1_UNIQUE [not found] ` <CAMe9rOorOgV6wT3gHVdfK-zKp11kUVcqtBZHSSd__EdQtWvcKw@mail.gmail.com> @ 2020-06-26 18:34 ` H.J. Lu 0 siblings, 0 replies; 8+ messages in thread From: H.J. Lu @ 2020-06-26 18:34 UTC (permalink / raw) To: Vivek Das Mohapatra, GNU gABI gnu-gabi, GNU C Library, Binutils On Fri, Jun 26, 2020 at 10:38 AM H.J. Lu <hjl.tools@gmail.com> wrote: > > On Fri, Jun 26, 2020 at 10:35 AM 'Fangrui Song' via Generic System V > Application Binary Interface <generic-abi@googlegroups.com> wrote: > > > > On 2020-06-26, Ali Bahrami wrote: > > >On 6/26/20 9:49 AM, H.J. Lu wrote: > > >>> I don't know about DF_1_UNIQUE specifically, > > >>>but on Solaris, all 32-bits of DT_FLAGS_1 > > >>>have already been defined, so we have a conflict. > > >>> > > >>>Perhaps this should move to a DT_GNU_* dynamic > > >>>entry that's part of the GNU OSABI? > > >>> > > >>How about DT_GNU_FLAGS_1 and DF_GNU_1_UNIQUE? > > > > > > > > > That would work for me. > > > > > >- Ali > > > > It seems that GNU specific dlmopen wants to have a libc.so/libpthread.so instance per namespace, but they need to > > share some data structures. (https://sourceware.org/pipermail/libc-alpha/2020-June/115139.html ) > > > > Even on Linux, I think this is very unlikely adopted by musl. > > It is said this flag may have something to do with LD_AUDIT. > > > > DT_GNU_FLAGS_1 and DF_GNU_1_UNIQUE are definitely fine. > > > > I will propose to gnu-gABI: > > #define DT_GNU_FLAGS_1 0x6ffffdf4 > #define DF_GNU_1_UNIQUE 0x00000001 > Here is the merge request to define DT_GNU_FLAGS_1 and DF_GNU_1_UNIQUE: https://gitlab.com/x86-psABIs/Linux-ABI/-/merge_requests/1 -- H.J. ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2020-06-26 18:34 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20200617135945.12716-1-vivek@collabora.com> [not found] ` <CAMe9rOr7PVkz1k8dAPXoJjiCjiQ32f26ZduMX6xuxbGzguG=zQ@mail.gmail.com> 2020-06-17 16:00 ` [RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE Vivek Das Mohapatra 2020-06-17 16:16 ` Michael Matz 2020-06-17 16:37 ` Vivek Das Mohapatra 2020-06-17 18:23 ` Cary Coutant 2020-06-17 19:13 ` Vivek Das Mohapatra 2020-06-26 15:12 ` [RFC][PATCH v3 0/6] binutils patches to add DF_1_UNIQUE Vivek Das Mohapatra 2020-06-26 15:29 ` H.J. Lu [not found] ` <ca72c789-f60c-2eaf-18e9-a7e59fcb0319@Oracle.COM> [not found] ` <CAMe9rOqF-zUUsCeyiT8s20bhTeVhozZtGkAD-JRrNiEOaju7jQ@mail.gmail.com> [not found] ` <8af0af5a-9fd4-2e80-1dff-ff714a15a6b2@Oracle.COM> [not found] ` <20200626173513.22arn2ihwgxudmjf@google.com> [not found] ` <CAMe9rOorOgV6wT3gHVdfK-zKp11kUVcqtBZHSSd__EdQtWvcKw@mail.gmail.com> 2020-06-26 18:34 ` H.J. Lu
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).