From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124722 invoked by alias); 10 Feb 2016 16:36:27 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 124708 invoked by uid 89); 10 Feb 2016 16:36:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=efficacy, questioning, GLIBC, Hx-languages-length:2954 X-HELO: mail-yw0-f176.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=msNMDgb5Lb7ux6rxDbNHrajRBw/1Bl0UJ4ny6azJtQE=; b=Nk0xdjH0Cws7Ms4u0YJXw/Lbv2N1QxFN9qQurZztMzOgZC/5WEzfwfvHrUg24J087a Z9fIIeJPooA+O4l4oKdRV6tXhYO+Kb88CPNkTdDYyuVMvL1e9V6koTcQAAgVxBgHOePN AEZ8S1cCSPkHyYoEyrhMRzkhOkQXbHtcAMmrj/JKlKMDZEdKTtMlB8Nzs7EAraJdRLi1 3pGiQ5aPgHtIBDKUcoZ1suCJTZ7zSpp6HOQNlsslZWgK6U2MBWRqZs3lu3IUn2q3jp41 v+maxcWBueqs/714enQLQDTM3qmjlNY5V5mStfz0IQ0B8/hIqgM1W2QziP4oPP192lXK Fgxw== X-Gm-Message-State: AG10YOTnKXhYQui/VbQCBWnFhrJ+8DLDyZ0lWH5THcG6CrMv0UZF4dV68dZtNyRnePK9ezop X-Received: by 10.129.52.12 with SMTP id b12mr11358532ywa.8.1455122183424; Wed, 10 Feb 2016 08:36:23 -0800 (PST) Subject: Re: [PATCH v2 1/3] posix: Remove dynamic memory allocation from execl{e,p} To: libc-alpha@sourceware.org References: <1454343665-1706-1-git-send-email-adhemerval.zanella@linaro.org> <1454343665-1706-2-git-send-email-adhemerval.zanella@linaro.org> <20160202163335.GJ9349@brightrain.aerifal.cx> <878u2wfbwv.fsf@rasmusvillemoes.dk> <56B9CF1A.6020807@twiddle.net> <56B9E9E8.9070401@arm.com> From: Adhemerval Zanella Message-ID: <56BB6704.3020506@linaro.org> Date: Wed, 10 Feb 2016 16:36:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B9E9E8.9070401@arm.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00250.txt.bz2 On 09-02-2016 11:30, Szabolcs Nagy wrote: > On 09/02/16 11:35, Richard Henderson wrote: >> On 02/08/2016 08:28 AM, Rasmus Villemoes wrote: >>> On Tue, Feb 02 2016, Rich Felker wrote: >>> >>>> On Mon, Feb 01, 2016 at 04:52:15PM +0000, Joseph Myers wrote: >>>>> On Mon, 1 Feb 2016, Adhemerval Zanella wrote: >>>>> >>>>>> + char *argv[argc+1]; >>>>>> + va_start (ap, arg); >>>>>> + argv[0] = (char*) arg; >>>>>> + for (i = 1; i < argc; i++) >>>>>> + argv[i] = va_arg (ap, char *); >>>>>> + argv[i] = NULL; >>>>> >>>>> I don't see how you're ensuring this stack allocation is safe (i.e. if >>>>> it's too big, it doesn't corrupt memory that's in use by other threads). >>>> >>>> There's no obligation to. If you pass something like a million >>>> arguments to a variadic function, the compiler will generate code in >>>> the caller that overflows the stack before the callee is even reached. >>>> The size of the vla used in execl is exactly the same size as the >>>> argument block on the stack used for passing arguments to execl from >>>> its caller, and it's nobody's fault but the programmer's if this is >>>> way too big. It's not a runtime variable. >>> >>> This is true, and maybe it's not worth the extra complication, but if >>> we're willing to make arch-specific versions of execl and execle we can >>> avoid the double stack use and the time spent copying the argv >>> array. That won't remove the possible stack overflow, of course, but >>> then it'll in all likelihood happen in the user code and not glibc. >> >> I like the idea. It's a quality of implementation issue, wherein by re-using the data that's (mostly) on the >> stack already we don't need twice again the amount of stack space for any given call. >> >> I think that Adhemerval's patch should go in as a default implementation, and various targets can implement the >> assembly as desired. >> >> I've tested the following on x86_64 and i686. I've compile-tested for x32 (but need a more complete x32 >> installation for testing), and alpha (testing is just slow). >> >> Thoughts? >> > > i think it is a hard to maintain, nasty hack > > is execl stack usage the bottleneck somewhere? > > to improve the stack usage in glibc, the extreme > wasteful cases should be fixed first. > (crypt uses >100k, strtod uses ???, etc) > > e.g. musl guarantees hard limits on libc stack usage > and execl is one of the (two) exceptions where it just > seems useless to do so (you cannot do it portably anyway). > I agree with Szabolcs and I also see these kind of asm specific implementation also adds platform different behaviour which I also think we should avoid to add within GLIBC. The only doubt with my patch I have now is if it is worth to add the -fstack-check or not. Florian has raised some questioning about its efficacy and I am not sure how well it is supported on all architectures.