[RFC][PATCH v2 0/6] binutils patches to add DT_GNU_UNIQUE

Vivek Das Mohapatra vivek@collabora.com
Wed Jun 17 22:29:08 GMT 2020


> Does DT_GNU_UNIQUE perform anything not done by DF_1_NODELETE (-z nodelete)?

Yes. This is not about deletion, but about whether there should only be one
copy of a DSO resident.

In normal use, the linked list of DSOs looks like this:

   ld.so → libc.so→  libA.so→  libB.so→  …

But when namespaces are available you can have more than one:

0:  ld.so → libc.so→  libA.so→  libB.so→  …

1:  ld.so → libc.so→  lDbA.so→  EibB.so→  …

2:  …

now ld.so is special cased so there's only one of it
ever in residence: namespaces 1 and up just get a
dummy struct which actually points at the on in namespace 0:

0:  ld.so → libc.so→  libA.so→  libB.so→  …
       ↑
1:  [dummy] → libc.so→  lDbA.so→  EibB.so→  …

But it turns out that having more than 1 libc.so or
libpthread.so (and so forth) causes some problematic
behaviour - we actually want the glibc cluster of
DSOs (and maybe one or two others, possibly libgcc)
to be unique in the same way. DT_GNU_UNIQUE is the hint
to the linker/loader that this should happen.


More information about the Binutils mailing list