From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2115 Path: news.gmane.org!not-for-mail From: boris brezillon Newsgroups: gmane.linux.lib.musl.general Subject: Re: TLS (thread-local storage) support Date: Tue, 16 Oct 2012 23:27:56 +0200 Message-ID: References: <20121004211332.GA12874@brightrain.aerifal.cx> <20121004223631.GL254@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1350422898 31558 80.91.229.3 (16 Oct 2012 21:28:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Oct 2012 21:28:18 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2116-gllmg-musl=m.gmane.org@lists.openwall.com Tue Oct 16 23:28:25 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 1TOEgY-0007TE-AR for gllmg-musl@plane.gmane.org; Tue, 16 Oct 2012 23:28:22 +0200 Original-Received: (qmail 7679 invoked by uid 550); 16 Oct 2012 21:28:14 -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 7652 invoked from network); 16 Oct 2012 21:28:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=rZJJKW3xErbY29c0dMShTp7lfzjmsOyaTKjtC9aGt3E=; b=Ly1YL8zraptnpPFodCfCSAEGTea/7gSCIcYZikcT8m7A9vA6Ay2iHG9heJDwcYh+Pw vvMVZvQD2HF5q2fRd4M/UdS8NI+ybs4Lp/QGfoExy5y+yMaOXDumSzBu11/aRn58byLn wz7SZiBUSHLZZL8oZnCUQ7eHNtjBFpy0Qfibh4FN4pQU8u+K+FcGadZpZP4MJU3y4PeS CdyWPfKqdD4jCj41N3tyQXQT86HwDjTPg/BUGN+Dlfma/Kp9VghrhciK64Ngg7RvIkyO dRUBrCPGQo0zJhWwrslzOU6C1O4KYgeuu0oy7cZ812ccvIWPV+Dp1qJK/7oWT3pJ+3Ut YuhQ== In-Reply-To: Xref: news.gmane.org gmane.linux.lib.musl.general:2115 Archived-At: Hi, First I'd like to thank Rich for adding TLS support (I started to work on it a few weeks ago but never had time to finish it). 2012/10/6 Daniel Cegie=C5=82ka : > 2012/10/5 Rich Felker : >> On Thu, Oct 04, 2012 at 11:29:11PM +0200, Daniel Cegie=C5=82ka wrote: >>> great news! Finally able to compile Go (lang)... >> >> Did Go fail with gcc's emulated TLS in libgcc? > > I tested Go with sabotage (with fresh musl). I'll try to do it again... > gcc in sabotage was compiled without support for TLS, so I didn't > expect that it will be successful: > > https://github.com/rofl0r/sabotage/blob/master/pkg/gcc4 > There's at least one thing (maybe more) missing for go support with musl : gcc 'split-stack' support (see http://blog.nella.org/?p=3D849 and http://gcc.gnu.org/wiki/SplitStacks). I'm also interested in split stack support in musl but for other reasons (thread and coroutine stack automatic expansion). For x86/x86_64 split stack is implemented using a field inside the pthread struct which is accessed via %fs (or %gs for x86_64) and an offset. Currently this offset is defined at 0x30 (0x70 for x86_64) by the TARGET_THREAD_SPLIT_STACK_OFFSET but only if TARGET_LIBC_PROVIDES_SSP is defined (see gcc/config/i386/gnu-user.h or gcc/config/i386/gnu-user64.h). As far as I know musl does not support stack protection, but we could at least patch gcc to define TARGET_THREAD_SPLIT_STACK_OFFSET when using musl. We also need to reserve a field in the musl pthread struct. There are currently two fields named 'unused1' and 'unused2' but I'm not sure they're really unused in every supported arch. BTW, I'd like to work on a more integrated support of split stack in MUSL : 1) support in dynamic linker (see the last point of http://gcc.gnu.org/wiki/SplitStacks) : check split stack notes in shared libs (and program ?) 2) support in thread implementation : currently when a thread is created the stack limit is set afterward (see https://github.com/mirrors/gcc/blob/master/libgcc/generic-morestack-thread.= c and https://github.com/mirrors/gcc/blob/master/libgcc/config/i386/morestack= .S) and the stack size is supposed to be 16K (which is the minimum stack size). This means we may reallocate a new stack chunk even if the previous one (the first one) is not fully used. If stack limit is set by thread implementation, this can be set appropriately according to the stack size defined by the thread creator. 3) more optimizations I haven't thought about yet... Do you have any concern about adding those features in musl ? Let me know if you see other issues I haven't noticed. Regards, Boris