[RFC,0/6] binutils patches to add DT_FLAGS_1 / DF_1_UNIQUE

  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_FLAGS_1 value DF_1_UNIQUE 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 DF_1_UNIQUE to ld, gold, and
readelf (and documents it in the help text and so forth).

Vivek Das Mohapatra (6):
  Define a new DT_FLAGS_1 flag DF_1_UNIQUE for ld, readelf et al
  Handle DF_1_UNIQUE in ld
  Document DF_1_UNIQUE in the man page and ld help output
  Handle DF_1_UNIQUE in readelf
  Define DT_FLAGS_1 flag DF_1_UNIQUE for gold
  Implement and document DF_1_UNIQUE handling in gold

 binutils/readelf.c   | 5 +++++
 elfcpp/elfcpp.h      | 4 +++-
 gold/layout.cc       | 2 ++
 gold/options.h       | 3 +++
 include/elf/common.h | 1 +
 ld/emultempl/elf.em  | 2 ++
 ld/ld.texi           | 7 +++++++
 ld/lexsup.c          | 2 ++
 8 files changed, 25 insertions(+), 1 deletion(-)
  

* Vivek Das Mohapatra via Libc-alpha:

> 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_FLAGS_1 value DF_1_UNIQUE 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 DF_1_UNIQUE to ld, gold, and
> readelf (and documents it in the help text and so forth).

I think you should repost this series to the binutils list.

It would perhaps be less controversial to add a new dynamic tag in the
GNU range for this, rather than a global flag value (in the space
shared with other operating systems).
  

> It would perhaps be less controversial to add a new dynamic tag in the
> GNU range for this, rather than a global flag value (in the space
> shared with other operating systems).

Ok, I'll do that. Thanks. Other than that, do you see any problems with
the implementation or documentation?
  

On Tue, 31 Mar 2020, Vivek Das Mohapatra via Libc-alpha wrote:

>> It would perhaps be less controversial to add a new dynamic tag in the
>> GNU range for this, rather than a global flag value (in the space
>> shared with other operating systems).
>
> Ok, I'll do that. Thanks. Other than that, do you see any problems with
> the implementation or documentation?

Finally got back round to this bit - could you tell me what the GNU range
is exactly? Did you mean put it in DT_FLAGS instead? or inbetween DT_LOOS
and DT_HIOS? Or something else?
  

* Vivek Das Mohapatra via Libc-alpha:

> On Tue, 31 Mar 2020, Vivek Das Mohapatra via Libc-alpha wrote:
>
>>> It would perhaps be less controversial to add a new dynamic tag in the
>>> GNU range for this, rather than a global flag value (in the space
>>> shared with other operating systems).
>>
>> Ok, I'll do that. Thanks. Other than that, do you see any problems with
>> the implementation or documentation?
>
> Finally got back round to this bit - could you tell me what the GNU range
> is exactly? Did you mean put it in DT_FLAGS instead? or inbetween DT_LOOS
> and DT_HIOS? Or something else?

Yes, I expect a constant value somewhere around DT_GNU_PRELINKED or
DT_GNU_HASH, depending on exact semantics.

Thanks,
Florian