From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74996 invoked by alias); 16 Jan 2017 16:31:32 -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 74968 invoked by uid 89); 16 Jan 2017 16:31:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1641, H*f:sk:a7261d6, H*MI:sk:a7261d6, H*i:sk:a7261d6 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; Mon, 16 Jan 2017 16:31:29 +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 71CE51515; Mon, 16 Jan 2017 08:31:28 -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 59C933F3D6; Mon, 16 Jan 2017 08:31:26 -0800 (PST) Date: Mon, 16 Jan 2017 16:31:00 -0000 From: Dave Martin To: Pedro Alves Cc: Yao Qi , linux-arch@vger.kernel.org, Florian Weimer , libc-alpha@sourceware.org, Ard Biesheuvel , Marc Zyngier , gdb@sourceware.org, Christoffer Dall , Szabolcs Nagy , linux-arm-kernel@lists.infradead.org, Alan Hayward , Torvald Riegel , Joseph Myers Subject: Re: [RFC PATCH 08/10] arm64/sve: ptrace: Wire up vector length control and reporting Message-ID: <20170116163123.GQ3699@e103592.cambridge.arm.com> References: <1484220369-23970-1-git-send-email-Dave.Martin@arm.com> <1484220369-23970-9-git-send-email-Dave.Martin@arm.com> <20170116122038.GG28060@E107787-LIN> <20170116133231.GO3699@e103592.cambridge.arm.com> <20170116151156.GI28060@E107787-LIN> 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: 2017-01/txt/msg00025.txt.bz2 On Mon, Jan 16, 2017 at 03:47:55PM +0000, Pedro Alves wrote: > On 01/16/2017 03:11 PM, Yao Qi wrote: > > > >> > > >> > gdb must already re-detect the vector length on stop, since the target > >> > could have called the prctl() in the meantime. > > Yes, gdb assumes the vector length may be changed, so it re-detects on > > every stop, but I don't see the need for gdb to change the vector length. > > > > Do we need to consider inferior function calls here? > > Say the program is stopped in code that assumes "vector length N", and > the user does "print some_function_that_assumes_some_other_vector_length ()". > > Is that a use case we need to cover? > > If so, to make it work correctly, the debugger needs to be able to change the > vector length to the length assumed by that called function, and then > restore it back after the call completes (or is aborted). > > I have no idea whether the debugger will be able to figure > out a function's assumed vector length from debug info or some such. I think the proposed ptrace interface can support this -- i.e., it should provide everything needed to save off the VL and register state, switch VL, do something else, then restore the VL and state (if not, that's a bug). My current position is that determining what vector length is required by what function or binary is a 100% userspace problem, though. ELF/DWARF could have annotations about this, though it wouldn't necessarily be per-function -- you might require a whole image to be built for the same vector length (if any). Cheers ---Dave