From owner-freebsd-threads@FreeBSD.ORG Wed Jan 7 05:14:58 2015 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7B761682; Wed, 7 Jan 2015 05:14:58 +0000 (UTC) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3BA4E64709; Wed, 7 Jan 2015 05:14:57 +0000 (UTC) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.14.9/8.14.9/NETPLEX) with ESMTP id t075EtkD034465; Wed, 7 Jan 2015 00:14:56 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Wed, 07 Jan 2015 00:14:56 -0500 (EST) Date: Wed, 7 Jan 2015 00:14:55 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: Konstantin Belousov Subject: Re: Fixing dlopen("libpthread.so") In-Reply-To: <20150107042053.GK42409@kib.kiev.ua> Message-ID: References: <20141226165337.GJ1754@kib.kiev.ua> <20150103212837.GC46373@stack.nl> <20150104114600.GC42409@kib.kiev.ua> <20150104182026.GA61250@stack.nl> <20150105023708.GD42409@kib.kiev.ua> <20150106205046.GA24971@stack.nl> <20150107032941.GJ42409@kib.kiev.ua> <20150107042053.GK42409@kib.kiev.ua> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: threads@freebsd.org, arch@freebsd.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jan 2015 05:14:58 -0000 On Wed, 7 Jan 2015, Konstantin Belousov wrote: > On Tue, Jan 06, 2015 at 11:01:30PM -0500, Daniel Eischen wrote: >> On Wed, 7 Jan 2015, Konstantin Belousov wrote: >> >>> On Tue, Jan 06, 2015 at 09:50:46PM +0100, Jilles Tjoelker wrote: >>>> On Mon, Jan 05, 2015 at 04:37:08AM +0200, Konstantin Belousov wrote: >>>>> Next natural question is about the __error calls through PLT in the >>>>> .cerror asm. Before the work was committed, libthr interposed __error, >>>>> which was required for correct operation. Now, we need __error exported, >>>>> but do we need support its interposing ? This is an implementation >>>>> detail for errno, I do not see any loss from not allowing to override >>>>> errno location. >>>> >>>> Indeed, there is no need to allow interposing __error (as with many >>>> libc-internal calls to its exported symbols). Additionally, the current >>>> namespace.h mechanism could be used to redirect __error calls from C >>>> code. >>>> >>>> Glibc uses macro trickery with the asm labels compiler feature, making >>>> libc code see things like >>>> int *__error(void) asm("__hidden__error"); >>>> and defining the hidden alias somewhere. This also works for >>>> compiler-generated calls like to memcpy(). I'm not sure whether it is a >>>> good idea to add this extra trickery and depend on the compiler feature. >>> I might look at this after the current change is committed. >> >> I don't quite follow all the above about __error(), but non-C >> programs need to interface to an __error() that works regardless >> of threading or not. > > C programs also need to be able to call __error(), to have working > errno. Discussion above talks about the need for the programs to be > able to interpose __error(), which I and Jilles agree is excessive. My > proposal is to remove PLT indirection in the calls to __error() from > _inside_ libc, which makes errno functioning in libc both more reliable > and slightly faster. Fair enough - thanks for the explanation! -- DE