How should STB_GNU_UNIQUE binding interact with RTLD_LOCAL ?

[Paul Pluzhnikov]

Greetings,

We've just switched to gcc-4.6 toolchain, and discovered an obscure set
of bugs, which are triggered by STB_GNU_UNIQUE symbols.

Effectively, STB_GNU_UNIQUE symbols always get installed in the global
scope, even when a library is loaded via dlopen(..., RTLD_LOCAL), making
it impossible to load two separate libraries sharing the same STB_GNU_UNIQUE
symbols and have them not interfere with each other.

That behavior appears counter-intuitive and contradicts the description
of RTLD_LOCAL:

This is the converse of RTLD_GLOBAL, and the default if neither flag
is specified. Symbols defined in this library are not made available
to resolve references in subsequently loaded libraries.

Is this really how it is supposed to work, or should RTLD_LOCAL "override"
STB_GNU_UNIQUE and keep them local?

Thanks,

[Roland McGrath]

AIUI, this is the fundamental purpose of STB_GNU_UNIQUE.

[Paul Pluzhnikov]

Post by Roland McGrath
AIUI, this is the fundamental purpose of STB_GNU_UNIQUE.

Thanks.

For what it's worth, we've decided that we simply can not live with
the current STB_GNU_UNIQUE behavior (and we do think it was
ill-conceived).

We are going to turn it off via a linker switch:
http://cygwin.com/ml/binutils/2011-10/msg00276.html

[Roland McGrath]

Post by Paul Pluzhnikov
For what it's worth, we've decided that we simply can not live with
the current STB_GNU_UNIQUE behavior (and we do think it was
ill-conceived).

I was not involved in its devising, and off hand I don't think the
discussion about it took place on this list. (I avoid deep C++ nonsense
when I can, though I now know just enough about this issue to be curious
about its background, motivations, and drawbacks.)

http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01240.html is the earliest
thing I've found quickly that talks about the rationale. If you think the
rationale is bogus, then you should take it up with Jason. Since I'm
curious, you can CC: me. But I don't think libc-alpha needs to hear all
that discussion. We're just supporting what the C++ gurus have said they
need, and all we need to hear about here is if the consensus of C++ gurus
changes.


Thanks,
Roland

[Cary Coutant]

Post by Roland McGrath
http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01240.html is the earliest
thing I've found quickly that talks about the rationale.  If you think the
rationale is bogus, then you should take it up with Jason.  Since I'm
curious, you can CC: me.  But I don't think libc-alpha needs to hear all
that discussion.  We're just supporting what the C++ gurus have said they
need, and all we need to hear about here is if the consensus of C++ gurus
changes.

For the case discussed in that email (a common library that two others
both depend on), I think the basic idea is sound. The problem is that
when the two separately-loaded libraries (i.e., the ones that both
depend on the common library) define the same symbol, that symbol is
also shared between the two libraries. That, along with the fact that
some symbols get STB_GNU_UNIQUE binding (e.g., statics in template
instantiations, statics in inlines) and other symbols don't (e.g.,
statics in non-template classes), leads to the issues that we're
seeing.

-cary