From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/2136 Path: news.gmane.org!not-for-mail From: musl Newsgroups: gmane.linux.lib.musl.general Subject: Re: TLS (thread-local storage) support Date: Wed, 17 Oct 2012 09:48:56 +0200 Message-ID: <507E62E8.9080601@gmail.com> References: <20121004223631.GL254@brightrain.aerifal.cx> <20121016225438.GT254@brightrain.aerifal.cx> <20121016234825.GV254@brightrain.aerifal.cx> <20121017004253.GW254@brightrain.aerifal.cx> <20121017015842.GX254@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 Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1350460160 6736 80.91.229.3 (17 Oct 2012 07:49:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Oct 2012 07:49:20 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-2137-gllmg-musl=m.gmane.org@lists.openwall.com Wed Oct 17 09:49:27 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 1TOONS-0003Ms-Po for gllmg-musl@plane.gmane.org; Wed, 17 Oct 2012 09:49:18 +0200 Original-Received: (qmail 1967 invoked by uid 550); 17 Oct 2012 07:49:11 -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 1957 invoked from network); 17 Oct 2012 07:49:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=F6EdQ10NFfewNV1I+aFHzg2glBwq80c2AK5oHAf2yz4=; b=oysm18XoOWs9kW7fKnD4sJ5h/0KichLzwAgpro3W6ZGg3QaXY1ufWh9pf//MEkYlpr cqeUu3gH6EjPzE2YbL1wEpHyU81yX3RhbyyfWcyap3Jq+iV/8wR2DDKkRTtalCLfHeaY SNW7BSbAktF/ehjtm+urjYrbvpW13KznMzJ2J6YJ9a0FrCjXX9EQqGYtjfMZg2upVJZa dJuY2spI1QAHF+/ta+FuTZiLi7Ii/KJ2ZNd/FHXNPF9h810jAzmk8z5Z9M6Rku+tkN6F AFW5U6daLqUGDnt3VTxBkVZF4cf8d3Qn1eQ0X5Dc2WL0FjgTTO6jFbEoRMHD5qqs2Qxr zhEg== User-Agent: Mozilla/5.0 (X11; Linux i686; rv:16.0) Gecko/20121011 Thunderbird/16.0.1 In-Reply-To: <20121017015842.GX254@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:2136 Archived-At: On 17/10/2012 03:58, Rich Felker wrote: > On Wed, Oct 17, 2012 at 03:49:33AM +0200, boris brezillon wrote: >> 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. > Where is this documented? The GCC manual doesn't mention anything > about -fno-split-stack having special behavior like that, so for lack > of any documentation otherwise, it "should" just be the option to turn > off -fsplit-stack.. You're right, I misunderstood how -fno-split-stack was implemented. I tried to compile a source file with -fno-split-stack and didn't find any 'no-split-stack' note in the generated object file. When I compile it with -fsplit-stack both 'no-split-stack' and 'split-stack' notes are added. > > I'm not claiming you're wrong, just that this all seems poorly > documented. > > Rich