From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/11580 Path: news.gmane.org!.POSTED!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: [PATCH 4/8] determine the existence of private futexes at the first thread creation Date: Fri, 23 Jun 2017 18:08:23 -0400 Message-ID: <20170623220823.GR1627@brightrain.aerifal.cx> References: <20170623170535.GM1627@brightrain.aerifal.cx> <20170623234825.161cdaf2@inria.fr> 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 1498255720 6996 195.159.176.226 (23 Jun 2017 22:08:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 23 Jun 2017 22:08:40 +0000 (UTC) User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-11593-gllmg-musl=m.gmane.org@lists.openwall.com Sat Jun 24 00:08:36 2017 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 1dOWkj-0001Xy-FA for gllmg-musl@m.gmane.org; Sat, 24 Jun 2017 00:08:33 +0200 Original-Received: (qmail 5263 invoked by uid 550); 23 Jun 2017 22:08:36 -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 5240 invoked from network); 23 Jun 2017 22:08:35 -0000 Content-Disposition: inline In-Reply-To: <20170623234825.161cdaf2@inria.fr> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:11580 Archived-At: On Fri, Jun 23, 2017 at 11:48:25PM +0200, Jens Gustedt wrote: > Hello Rich, > > On Fri, 23 Jun 2017 13:05:35 -0400 Rich Felker wrote: > > > This was intentional, the idea being that a 100% predictable branch in > > a path where a syscall is being made anyway is much less expensive > > than a GOT address load that gets hoisted all the way to the top of > > the function and affects even code paths that don't need to make the > > syscall. Whether it was a choice that makes sense overall, I'm not > > sure, but that was the intent. > > So if we can avoid going through GOT, this would be better? > I'd just add ATTR_LIBC_VISIBILITY to the variable, and then this > should go away the same way as it is done for the libc object. It's not going through the GOT that's costly, but actually getting the GOT address, which is used for both accesses through the GOT and GOT-relative addressing. On several archs including i386, PC-relative addressing is not directly available and requires hacks to load the PC into a GPR, and these usually take some cycles themselves and spill out of the free call-clobbered registers so that additional stack shuffling is needed. Rich