From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13589 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: pthread_key_create bug? Date: Tue, 8 Jan 2019 19:29:53 -0500 Message-ID: <20190109002953.GA23599@brightrain.aerifal.cx> References: <84B22C11-AA93-47FD-8352-A4F18B19F689@gmail.com> <5c1d9cf6-1b53-7082-5dee-8673ed4c55e9@adelielinux.org> <20190107021128.GW23599@brightrain.aerifal.cx> <20190107171327.GD29911@voyager> <20190108000018.GZ23599@brightrain.aerifal.cx> <20190108221006.GF29911@voyager> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1546993683 11444 195.159.176.226 (9 Jan 2019 00:28:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 9 Jan 2019 00:28:03 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13605-gllmg-musl=m.gmane.org@lists.openwall.com Wed Jan 09 01:27:59 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.84_2) (envelope-from ) id 1gh1iv-0002rT-LA for gllmg-musl@m.gmane.org; Wed, 09 Jan 2019 01:27:57 +0100 Original-Received: (qmail 19788 invoked by uid 550); 9 Jan 2019 00:30:06 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 19769 invoked from network); 9 Jan 2019 00:30:06 -0000 Content-Disposition: inline In-Reply-To: <20190108221006.GF29911@voyager> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13589 Archived-At: On Tue, Jan 08, 2019 at 11:10:06PM +0100, Markus Wichmann wrote: > On Mon, Jan 07, 2019 at 07:00:18PM -0500, Rich Felker wrote: > > I think you're right, though we don't generally use weak references in > > musl on the basis (perhaps somewhat dubious) that they're an > > additional toolchain feature that might cause problems reusing the > > code in non-ELF contexts (this may affect midipix; I'm not sure). > > That's why weak aliases to dummy functions are used for this purpose > > everywhere else. > > > > I don't quite get you. Weak aliases are just weak references with a > non-zero default value. Any toolchain being able to handle weak aliases > should be able to handle weak references, right? No, not necessarily, and no they're not equivalent to weak definitions with a zero value. A weak definition with a zero value would provide a definition for other translation units to see/use, preventing one with a non-weak reference from pulling in the real definition. Weak references are a property of the reference. Weak definitions are a property of the definition. They are not in any way equivalent. In any case, the policy is that we don't use weak references (*). If there were a strong reason to want them, we could review the reasons and see if they are still relevant. (*) This is only partly true. There are weak references to some special ELF symbols defined by the linker, because providing a weak definition would override the linker-provided value. For these, there will never be definitions provided by source files, so the weak reference is mostly equivalent to a weak definition by your above logic. Furthermore, we know they'll always be defined for position-independent linking (_DYNAMIC has to exist for shared libraries and PIE) so there is no concern about the issue below (PC-relative references to an undefined weakly-referenced symbol). > > Also: weak references to hidden functions historically had some > > breakage with respect to generating unresolvable-at-ld-time > > pc-relative references to the symbol. Thus their use might break some > > gcc/binutils versions too. > > OK, that's interesting. But do we really want to work around bugs in > gcc/binutils? Especially ones that were fixed a while ago? Because that > might lead us to a situation where we have ugly code we can't improve > because an old version of binutils had a bug, which is a fact that will > never go away, so the code stays ugly forever. It depends on the situation. In this case the functionality itself is an extension to the language and it's not formally defined exactly what usage is valid; we have to infer that from what the tools do and how they're documented. The whole point here is to minimize the extent to which we depend on behavior that has historically differed between tools, so that we don't get bogged down worrying about the specifics of it. Rich