[PATCH] Fix handling of STB_GNU_UNIQUE in LD_TRACE_PRELINKING

[Jakub Jelinek <jakub at redhat dot com>]

Hi!

The STB_GNU_UNIQUE hash table breaks computation of conflicts
during LD_TRACE_PRELINKING, thus prelink doesn't add relocations into
.gnu.conflict section and programs might misbehave at runtime when
prelinked.

The problem is that to detect a conflict, _dl_debug_bindings in addition
to the normal lookup does also a lookup in undef_map->l_local_scope[0],
and if the lookup has different result, reports a conflict, otherwise
just non-conflicting lookup.  But, as STB_GNU_UNIQUE hash table for
such symbols always gives the first lookup that entered the hash table,
conflicts are never reported for STB_GNU_UNIQUE lookups.

Attached are two possible patches.  The second, shorter one, is all that is
needed currently (I believe).  The difference between the patches is in
handling libraries with DT_SYMBOLIC and STB_GNU_UNIQUE symbols.  Apparently
current GNU ld if there is a relocation against STB_GNU_UNIQUE symbol
defined in the library itself, doesn't emit any relocation and resolves at
link time (possibly through a relative relocation).  Is that what we want
though?  Then the STB_GNU_UNIQUE symbols aren't really unique...

If we want to change ld(1) behavior to always emit dynamic relocations
against STB_GNU_UNIQUE symbols defined in the library even
for -Wl,-Bsymbolic, then I'm afraid we need something like the former patch.
It can be pessimizing, reporting a conflict even when there is really none,
but I don't see how else to do this cheaply.  And, -Wl,-Bsymbolic is very
rare I believe, so I don't care about that too much.

	Jakub

Attachment: S
Description: Text document

Attachment: S2
Description: Text document