From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41805 invoked by alias); 16 Nov 2016 15:55:08 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 41721 invoked by uid 89); 16 Nov 2016 15:55:07 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=wind, nondefault, non-default, _do_ X-HELO: mail-qk0-f195.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=7X3EiRK6tX3bJuXCXO6TLBtJRNYQmjPKQcqi8G4WvVo=; b=d1fnosMstY8dWXu9g1Ej5vnvFK3zvE3IUPxHBg6wNefWqjLfa3amOUUxo5fj9Swr15 wnysKaWC5Cmgw8VJ4GrBw4cfCVCrtXypndc+nRk8nV0oLy+rQcexPbGxgo99bSbPhq9J La4ZYG8LxrD6EfEPM/TUJDeuYTMBAwkKNxGjE1KZf9vnbRQ5ikStyXWPFS6ornGPAogG Y8MjP6mi5p05Kw63Vz3CX2DgvzchA4gcydgoR6z7GivqqiobjPKt5jImpkQd05CrYYso 3g6DwvYD8jTOcs4ckLGgGQr2C1CyNSvOykxFBbWMb0rsqU3N3HfyKnKx5fR4E61/Wajs 8ImA== X-Gm-Message-State: AKaTC02ksJan41FrRsa0KP/HiorOy48JiDGYbPRAmlgQSu7Su5e0loucys+zY3mG1jEc7g== X-Received: by 10.55.207.134 with SMTP id v6mr4585076qkl.105.1479311702366; Wed, 16 Nov 2016 07:55:02 -0800 (PST) Subject: Re: Evolution of ELF symbol management To: libc-alpha@sourceware.org References: <9727f95a-df3d-ec11-8c1d-9b7ea6cbcaac@redhat.com> From: Zack Weinberg Message-ID: <0c682496-5c13-b3c5-ff66-0f8923a1d6e3@panix.com> Date: Wed, 16 Nov 2016 15:55:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.4.0 MIME-Version: 1.0 In-Reply-To: <9727f95a-df3d-ec11-8c1d-9b7ea6cbcaac@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-SW-Source: 2016-11/txt/msg00570.txt.bz2 On 10/18/2016 05:26 AM, Florian Weimer wrote: > With this message, I want to start a discussion why this symbol > mangling stops at glibc-internal cross-DSO references (or static > linking). Wouldn't other system libraries, such as libstdc++, glib, > Qt and so on need to do the same thing? After all, if Qt calls > foo@GLIBC_2.31, and the main program defines foo (which the static > linker automatically exports to enable interposition), we almost > certainly would want Qt to continue to call foo@GLIBC_2.31, and not > the potentially incompatible implementation of foo in the main > program. > > To keep things simple, I suggest that for all new function symbols, > we declare __libc_foo in the header file, redirect foo to > __libc_foo, export both at the same symbol version from the DSO, and > make __libc_foo a strong definition and foo a weak one. (We should > not add new variable symbols.) > > For existing symbols, we only do this if we receive reports of > conflicts causing problems in the field. In this case, we add > __libc_foo and the redirect to the header file, and use the current > symbol version for the __libc_foo export (not the one of foo). I meant to respond to this last month but have not been able to scrape time away from $DAYJOB until this week. Apologies. First, I don't have a problem with adding __libc_* aliases as non-default but public alternative names, so that third-party libraries can avoid namespace pollution in static linkage and/or choose to refer to symbols that are more likely to get resolved to the C library's export than to a colliding symbol in the main executable. I'd reserve that for cases where there is already a demonstrated need, though, such as libstdc++. I also don't have a problem with a hypothetical policy that all new symbols that aren't in the current revisions of C+POSIX should be given an impl-namespace name as their primary definition, with the user-namespace name being a weak alias (but still the only name used in the public headers). I _do_ have problems with causing these symbols to be used by default. My main concern is that I think it's tackling the problem in the wrong place. If we want to back away from the original principle that the executable always wins, isn't an expanded version of -Bsymbolic mode what's _really_ wanted? That is, an opt-in link-time declaration that you want all dynamic symbols resolved at load-time to the same library that provided them at link-time. Once that exists, we could try to move slowly in the direction of turning it on by default, along with various other "yes, fix the bug" linker toggles like -z relro and --as-needed. Until and unless this possibility has been thoroughly explored and determined unworkable, I will object to bulk addition of __libc_* aliases, and to an "all new public prototypes must redirect to a __libc_* alias" rule. A secondary reason for not wanting __libc_* aliases to be activated by default is that it doesn't seem to me that it actually solves the problem. Applications that _want_ to interpose are going to shift to the __libc_* names; depending on what the headers actually do, applications that don't care (but do define a conflicting symbol) might wind up shifting to those names by accident. __REDIRECT doesn't work without GCC(-compatible) extensions, after all. (I would not object to a _documented and enforced_ set of GCC-compatible extensions being a baseline requirement for use of glibc headers -- but that would need to happen _first_.) zw