From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2119 Path: news.gmane.org!not-for-mail From: boris brezillon Newsgroups: gmane.linux.lib.musl.general Subject: Re: TLS (thread-local storage) support Date: Wed, 17 Oct 2012 01:16:43 +0200 Message-ID: References: <20121004211332.GA12874@brightrain.aerifal.cx> <20121004223631.GL254@brightrain.aerifal.cx> <20121016220922.GO24157@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 X-Trace: ger.gmane.org 1350429422 19149 80.91.229.3 (16 Oct 2012 23:17:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Oct 2012 23:17:02 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2120-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 17 01:17:10 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 1TOGNj-00080Y-2J for gllmg-musl@plane.gmane.org; Wed, 17 Oct 2012 01:17:03 +0200 Original-Received: (qmail 25690 invoked by uid 550); 16 Oct 2012 23:16:55 -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 25681 invoked from network); 16 Oct 2012 23:16:55 -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; bh=CxSgpSDmgu8dLo074uM69hb92Lo2cmRB8KoWZRYiaPY=; b=EYi09xmOL9jyoWZaLNMwfymW8gKXrTmdiOWyY+WTnenlQ0SDntFvyMLtcSRSKfNNkQ 8DU8bx2l1Me+VuAG3YtBum5U9T5X8xcMcv/Gb4lekjlZ28jr1l0qekW+2SXrDHScVSP+ ueQKdbyvzXy2+NLd3vU/mnKpbLChPUEmoCpHodXPLQ0VO/2Jt1jdwO1vlJLp/PIPYVhp wWZury12FtLUz0npeAfH9QskYt3irYLnBTT4SPiiPrMnUjuyPjOzQdXLbEPNkJe3hg5r qnVeYknFLCUMYUUf2ZHAtYh6nfIbzO/nOp0Syoj3cIVbfr5SoVoOIQO/m/EIklO6Nfuk UKgQ== In-Reply-To: <20121016220922.GO24157@port70.net> Xref: news.gmane.org gmane.linux.lib.musl.general:2119 Archived-At: 2012/10/17 Szabolcs Nagy : > * boris brezillon [2012-10-16 23:47:52 +0200]: >> > There's at least one thing (maybe more) missing for go support with >> > musl : gcc 'split-stack' support (see http://blog.nella.org/?p=849 and >> > http://gcc.gnu.org/wiki/SplitStacks). >> > > > why does go need support from libc? You're right: 1) I was talking about gccgo but I realized there's another compiler (gc go) which does not rely on gcc at all. 2) split stack is not mandatory for gccgo (see libgo/configure.ac in gcc sources) But it's still possible to enable split-stack and in this case go runtime relies on some libc functions (see libgcc/generic-morestack*). > > it has its own runtime and libraries on raw syscalls > >> 4) Compile musl with '-fsplit-stack' and add no_split_stack attribute >> to appropriate functions (at least all functions called before >> pthread_self_init because %gs or %fs register is unusable before this >> call). >> > > what does a no_split_stack function do when it runs out of stack? Segfault. no_split_stack attribute is used for leaf functions or functions call tree where the maximum stack size never exceed the reserved space for extra stack chunk allocation (I don't remember the exact value). > > most functions in musl may be run before pthread_self_init > (it runs on demand when a pthread function is used) This can be done during dynamic linking process (by checking the split stack note). > > what's the use of split stack if some functions may not work with it? Only the explicitly specified functions (no_split_stack attribute) won't include the split stack prolog. This is the developer's responsability to carefully choose which one to tag as 'no_split_stack'.