Re: [RFC][PATCH v3 0/6] binutils patches to add DF_1_UNIQUE

[H.J. Lu]

On Fri, Jun 26, 2020 at 8:12 AM Vivek Das Mohapatra via Gnu-gabi
<gnu-...@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.

[Ali Bahrami]

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?

- Ali

[H.J. Lu]

How about DT_GNU_FLAGS_1 and DF_GNU_1_UNIQUE?

--
H.J.

[Ali Bahrami]

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

[Fangrui Song]

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.

[H.J. Lu]

I will propose to gnu-gABI:

#define DT_GNU_FLAGS_1 0x6ffffdf4
#define DF_GNU_1_UNIQUE 0x00000001

--
H.J.