From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/4718 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Transition path for removing lazy init of thread pointer Date: Mon, 24 Mar 2014 21:55:32 -0400 Message-ID: <20140325015531.GB23474@brightrain.aerifal.cx> References: <20140324174915.GA1263@brightrain.aerifal.cx> <20140324230405.GA23163@brightrain.aerifal.cx> <5330C769.6080304@skarnet.org> 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 1395712535 29331 80.91.229.3 (25 Mar 2014 01:55:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Mar 2014 01:55:35 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-4722-gllmg-musl=m.gmane.org@lists.openwall.com Tue Mar 25 02:55:45 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1WSGae-0000Yv-UG for gllmg-musl@plane.gmane.org; Tue, 25 Mar 2014 02:55:45 +0100 Original-Received: (qmail 13962 invoked by uid 550); 25 Mar 2014 01:55:44 -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 13951 invoked from network); 25 Mar 2014 01:55:44 -0000 Content-Disposition: inline In-Reply-To: <5330C769.6080304@skarnet.org> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:4718 Archived-At: On Tue, Mar 25, 2014 at 12:01:45AM +0000, Laurent Bercot wrote: > >Static linked non threaded programs sounds like a good target. > > +1. > Most of my userspace is made of statically linked, non-threaded > programs, and I would love if musl was optimal for it. > Also, what is the mandatory first syscall on startup ? With > musl-0.9.15, on kernel 3.2.something, there is no syscall at all > (except execve(), of course) when starting a non-threaded program. The mandatory syscall is set_thread_area or equivalent, e.g. arch_prctl on x86_64. It's there because most archs need a syscall to set the thread pointer used for accessing TLS. Even in single-threaded programs, there are reasons one may want to have it. The big reason is that, on most archs, stack protector's canary value is stored at a fixed offset from the thread pointer rather than in a global, so stack protector can't work without the thread pointer being initialized. Up to now we've tried to detect whether stack protector is used based on symbol references to __stack_chk_fail, but this check gives a false negative (and thus crashing programs) if gcc optimizes out the check to __stack_chk_fail but not the load of the canary, e.g. in the program: int main() { exit(0); } The other main reason is that lazy initialization is a lot more expensive at runtime. All sorts of functions that need the thread pointer (mainly synchronization primitives, like pthread_mutex_lock when working with a recursive, error-checking, or robust mutex) previously had to call a fairly heavy pthread_self() function that performed the lazy initialization. Now they can just use an inline implementation (usually asm) that obtains the thread pointer, and for some functions having this inline means they're leaf functions and the compiler can eliminate a lot of ugly prologue/epilogue/spilling needed for non-leaf functions. So despite always initializing the thread pointer kinda looking like "bloat" from a minimal-program standpoint, it's really a major step forward in debloating and simplifying lots of code. Rich