[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