From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 70096 invoked by alias); 2 Dec 2016 11:49:01 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 70041 invoked by uid 89); 2 Dec 2016 11:48:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=statements X-Spam-User: qpsmtpd, 2 recipients X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Dec 2016 11:48:57 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C1FCA16; Fri, 2 Dec 2016 03:48:55 -0800 (PST) Received: from e103592.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3826A3F318; Fri, 2 Dec 2016 03:48:54 -0800 (PST) Date: Fri, 02 Dec 2016 11:49:00 -0000 From: Dave Martin To: Florian Weimer Cc: Yao Qi , libc-alpha@sourceware.org, Ard Biesheuvel , Marc Zyngier , gdb@sourceware.org, Christoffer Dall , Alan Hayward , Torvald Riegel , linux-arm-kernel@lists.infradead.org Subject: Re: [RFC PATCH 00/29] arm64: Scalable Vector Extension core support Message-ID: <20161202114850.GQ1574@e103592.cambridge.arm.com> References: <20161130120654.GJ1574@e103592.cambridge.arm.com> <3e8afc5a-1ba9-6369-462b-4f5a707d8b8a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3e8afc5a-1ba9-6369-462b-4f5a707d8b8a@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-12/txt/msg00003.txt.bz2 On Wed, Nov 30, 2016 at 01:38:28PM +0100, Florian Weimer wrote: [...] > We could add a system call to get the right stack size. But as it depends > on VL, I'm not sure what it looks like. Particularly if you need determine > the stack size before creating a thread that uses a specific VL setting. I missed this point previously -- apologies for that. What would you think of: set_vl(vl_for_new_thread); minsigstksz = get_minsigstksz(); set_vl(my_vl); This avoids get_minsigstksz() requiring parameters -- which is mainly a concern because the parameters tomorrow might be different from the parameters today. If it is possible to create the new thread without any SVE-dependent code, then we could set_vl(vl_for_new_thread); new_thread_stack = malloc(get_minsigstksz()); new_thread = create_thread(..., new_thread_stack); set_vl(my_vl); which has the nice property that the new thread directly inherits the configuration that was used for get_minsigstksz(). However, it would be necessary to prevent GCC from moving any code across these statements -- in particular, SVE code that access VL- dependent data spilled on the stack is liable to go wrong if reordered with the above. So the sequence would need to go in an external function (or a single asm...) Failing that, we could maybe define some extensible struct to get_minsigstksz(). Thoughts? Cheers ---Dave