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

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