From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40802 invoked by alias); 15 Sep 2016 16:45:52 -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 40788 invoked by uid 89); 15 Sep 2016 16:45:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=massage, ld.so, UD:ld.so, ldso X-HELO: foss.arm.com Date: Thu, 15 Sep 2016 16:45:00 -0000 From: Dave Martin To: Florian Weimer Cc: Szabolcs Nagy , nd@arm.com, libc-alpha@sourceware.org, linux-arm-kernel@lists.infradead.org, Ard Biesheuvel Subject: Re: [RFC PATCH 0/5] arm64: Signal context expansion Message-ID: <20160915164543.GB1574@e103592.cambridge.arm.com> References: <1473430576-20792-1-git-send-email-Dave.Martin@arm.com> <20160909152047.GA3958@e103592.cambridge.arm.com> <20160912111749.GB3958@e103592.cambridge.arm.com> <57D6C33D.9020003@arm.com> <20160912153015.GD3958@e103592.cambridge.arm.com> <9969568a-f969-d904-52b3-14f80c3abec4@redhat.com> <20160913155151.GA1574@e103592.cambridge.arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-09/txt/msg00267.txt.bz2 On Tue, Sep 13, 2016 at 06:02:45PM +0200, Florian Weimer wrote: > On 09/13/2016 05:52 PM, Dave Martin wrote: > > >Agreed. I'll need to think some more about how this should work in > >general. > > Thanks. > > Depending on some SVE implementations details (which I know nothing about, I > only saw some public overview slides), we may also need additional storage > space to preserve SVE registers in the dynamic linker. Due to lazy binding, > this code cn be called from a signal handler, so this needs to be factored > into stack size requirements as well. Yes and no. The kernel SIGSTKSZ constants don't care about ld.so -- that's userspace overhead, not kernel overhead. But it is a potential ABI issue for userspace; libc will need to massage the constants appropriately for its own implementation, and we do need to make sure that the kernel doesn't use up more stack on signal delivery than userspace expects. > Problematic are register width extensions used for argument passing and > callee-saved registers whose width has been extended. Both are particularly > challenging to deal with if existing vector instructions clear the extension > part (which may be desirable for other reasons). > > The size of the jmp_buf type is a concern as well. The default PCS for SVE will not be introducing any extra save/restore requirements for SVE -- i.e., everything is caller-save at public interfaces, except for the FPSIMD register bits that are already callee- save under the existing PCS. Some work will be needed as and when support is introduced for using an SVE-specific PCS at public interfaces. Interprocedural optimisation and LTO within individual shared libs need not depend on this, but I'm not sure how it will work in detail. Cheers ---Dave