From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8429 Path: news.gmane.org!not-for-mail From: Alexander Monakov Newsgroups: gmane.linux.lib.musl.general Subject: STB_GNU_UNIQUE not handled as original spec intended Date: Mon, 31 Aug 2015 15:51:16 +0300 (MSK) Message-ID: Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1441025507 31765 80.91.229.3 (31 Aug 2015 12:51:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 31 Aug 2015 12:51:47 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8441-gllmg-musl=m.gmane.org@lists.openwall.com Mon Aug 31 14:51:37 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZWOYg-0003NG-Ju for gllmg-musl@m.gmane.org; Mon, 31 Aug 2015 14:51:34 +0200 Original-Received: (qmail 27820 invoked by uid 550); 31 Aug 2015 12:51:32 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 27737 invoked from network); 31 Aug 2015 12:51:27 -0000 User-Agent: Alpine 2.20 (LNX 67 2015-01-07) Xref: news.gmane.org gmane.linux.lib.musl.general:8429 Archived-At: Hello, At present the dynamic linker in musl handles STB_GNU_UNIQUE not in the way the original spec intended. Which is not necessarily a bad thing, but the confusion about what that symbol binding type is supposed to convey probably is. Given that the commit that introduced handling into dynlink.c said: commit e152ee9778846c1f233641b2d3562ccdb081c6a9 Author: Rich Felker Date: Wed Jul 24 11:53:23 2013 -0400 support STB_GNU_UNIQUE symbol bindings in dynamic linker these are needed for some C++ library binaries including most builds of libstdc++. I'm not entirely clear on the rationale. this patch does not implement any special semantics for them, but as far as I can tell, no special treatment is needed in correctly-linked programs; this binding seems to exist only for catching incorrectly-linked programs. ...it seems that either reasons for STB_GNU_UNIQUE were unclear at that time, or I'm missing what "correctly-linked programs" was supposed to mean. :) So, to reiterate, my goal here is to show what STB_GNU_UNIQUE is supposed to achieve, and make sure that choice made in musl is clear. In the end of this email I'm pasting a minimal testcase that fails with musl. STB_GNU_UNIQUE is marking a data symbol that should be unique in a running program, *even when DSOs defining that symbol are all loaded with RTLD_LOCAL*. Apart from behavior under dlopen(..., ... | RTLD_LOCAL), I don't see any way it's different from a normal binding. The original cause for the new binding type was a desire to support dlopen'ed plugins implemented in C++ that reference data expected to be unified in normal link (via what C++ calls "vague linkage"). These are emails from when the binding was introduced: https://gcc.gnu.org/ml/gcc-patches/2009-07/msg01240.html https://www.redhat.com/archives/posix-c++-wg/2009-August/msg00002.html At the moment, my personal view is that STB_GNU_UNIQUE made things messier. The way it overrides RTLD_LOCAL sometimes makes it harder to reason about program behavior, and the way it's opt-out rather than opt-in makes it easier to accidentally write code that works on Linux with modern toolchain, but fails with old toolchain, or other OSes without a similar binding type. Here are some emails from people dissatisfied with the development: https://sourceware.org/ml/binutils/2011-10/msg00276.html https://sourceware.org/ml/libc-alpha/2011-10/msg00066.html Hope that clears things up. Alexander cat <<'EOF' >Makefile test: main libfoo.so libbar.so ./main main: LDLIBS=-ldl lib%.so: %.cc $(CC) -fPIC -shared -o $@ $< EOF cat <<'EOF' >bar.cc #include "singleton.h" extern "C" int bar() { return Singleton::getInstance()++; } EOF cat <<'EOF' >foo.cc #include "singleton.h" extern "C" int foo() { return Singleton::getInstance(); } EOF cat <<'EOF' >main.c #include int main() { void *libfoo = dlopen("./libfoo.so", RTLD_NOW); void *libbar = dlopen("./libbar.so", RTLD_NOW); int (*foo)(void) = dlsym(libfoo, "foo"); int (*bar)(void) = dlsym(libbar, "bar"); bar(); return !foo(); } EOF cat <<'EOF' >singleton.h template struct Singleton { static T& getInstance() { static T instance; return instance; } }; EOF