From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/557 Path: news.gmane.org!not-for-mail From: Solar Designer Newsgroups: gmane.linux.lib.musl.general Subject: Re: tough choice on thread pointer initialization issue Date: Fri, 10 Feb 2012 11:40:02 +0400 Message-ID: <20120210074002.GA13559@openwall.com> References: <20120210025824.GA25414@brightrain.aerifal.cx> 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: dough.gmane.org 1328859606 11379 80.91.229.3 (10 Feb 2012 07:40:06 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 10 Feb 2012 07:40:06 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-558-gllmg-musl=m.gmane.org@lists.openwall.com Fri Feb 10 08:40:05 2012 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 1Rvl5R-0008WQ-3o for gllmg-musl@plane.gmane.org; Fri, 10 Feb 2012 08:40:05 +0100 Original-Received: (qmail 1503 invoked by uid 550); 10 Feb 2012 07:40:04 -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 1495 invoked from network); 10 Feb 2012 07:40:04 -0000 Content-Disposition: inline In-Reply-To: <20120210025824.GA25414@brightrain.aerifal.cx> User-Agent: Mutt/1.4.2.3i Xref: news.gmane.org gmane.linux.lib.musl.general:557 Archived-At: Hi Rich, Thank you for posting this! On Thu, Feb 09, 2012 at 09:58:25PM -0500, Rich Felker wrote: > approach 1: hack the signal-return "restore" function to save the > current thread register value into the struct sigcontext before > calling SYS_sigreturn, so that it will be preserved when the > interrupted code resumes. > > pros: minimal costs, never adds any syscalls versus current musl. > > cons: ugly hack, and gdb does not like non-canonical sigreturn > functions (it refuses to work when the instruction pointer is at > them). > > > approach 2: call pthread_self() from sigaction(). this will ensure > that a signal handler never runs prior to the thread pointer being > initialized. > > pros: minimal code changes, and avoids adding syscalls except for > programs that use signals but not threads. > > cons: adds a syscall, and links unnecessary thread code when static > linking, in any program that uses signal handlers. I think another con of the two approaches above is that they'll fail if a program sets up a signal handler in a way bypassing musl (and other prerequisites of the problem are met as well, as you described them). Indeed, this makes it even more of a special case, but it's still legal (or not? that's a musl policy thing I guess). > approach 3: always initialize the thread pointer from > __libc_start_main (befoe main runs). (this is the glibc approach) ... > before i make a decision, i'd like to hear if anyone from the > community has strong opinions one way or the other. i've almost ruled > out approach #1 and i'm leaning towards #3, with the idea that > simplicity is worth more than a couple trivial syscalls. Not a strong opinion, but how about: approach 4: initialize the thread pointer register to zero at program startup. Then before its use, just check it for non-zero instead of checking a global flag. (I presume that you're doing the latter now, based on your description of the problem.) Alexander