From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2126 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 03:49:33 +0200 Message-ID: References: <20121004211332.GA12874@brightrain.aerifal.cx> <20121004223631.GL254@brightrain.aerifal.cx> <20121016225438.GT254@brightrain.aerifal.cx> <20121016234825.GV254@brightrain.aerifal.cx> <20121017004253.GW254@brightrain.aerifal.cx> 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 1350438586 19673 80.91.229.3 (17 Oct 2012 01:49:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Oct 2012 01:49:46 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2127-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 17 03:49:53 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 1TOIld-0004ZX-8B for gllmg-musl@plane.gmane.org; Wed, 17 Oct 2012 03:49:53 +0200 Original-Received: (qmail 31760 invoked by uid 550); 17 Oct 2012 01:49:46 -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 31752 invoked from network); 17 Oct 2012 01:49:45 -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=9IbdA71eer9cj+98N2NftDhzDqUxcysaIGzehoTGgOw=; b=NSonvJad/Sp9XOvOQ2nNod76EmokDVH0qsrghbQgPG0/0JbtBQvsWzAL00I2i5rxwA 1/LkFALVT22O6ZjcCrKwJCV+88uNlPL3JTih1EXepUXD7gIWIj4VYKo2dFO+Rk7gmGSt T9QyPdrkwKvRSukBLL2EN2UqPR2X5aUKBrEXfHuLY/XyQQuEVYrjfOIJzE/B/wOcSwBk luDJrc23v3sLLgCHkKGZH1U1sG33UIGXm2Of5QWqdtw7HucaZ0rILztLKwhtHIbjkadQ 2/ZvggjXBGRBdUfeoOZz0ZcAe97BJ1V2++u7SVHLv/DTF0SMOYntL1VJxWQ7uTqkSJxf A1Pg== In-Reply-To: <20121017004253.GW254@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:2126 Archived-At: 2012/10/17 Rich Felker : > On Wed, Oct 17, 2012 at 02:08:11AM +0200, boris brezillon wrote: >> >> I agree. This should be made optional. But if we don't compile libc >> >> with fsplit-stack (-fnosplit-stack). >> >> Each call to a libc func from an external func compiled with split >> >> stack may lead to a 64K stack chunk alloc. >> > >> > Where does this allocation take place from? There should simply be a >> > way to inhibit it. >> In the linker (gold linker). > > Well gold isn't running at runtime. I assume you mean it _arranges_ > for this allocation to take place somehow, and that's what I'm > wondering about whether there's a way to avoid. The easiest way to avoid big stack chunk allocation is to compile musl with -fno-split-stack option. This will not add any overhead to functions (no split stack prolog) And this will add a note to the shared object which tells the linker to avoid __morestack to __morestack_non_split replacement. > > Rich