From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7942 invoked by alias); 17 Jan 2017 10:04:00 -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 7911 invoked by uid 89); 17 Jan 2017 10:03:59 -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=objection, sk:sve_set, usefulness, 56pm 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; Tue, 17 Jan 2017 10:03:58 +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 450C8AD7; Tue, 17 Jan 2017 02:03:56 -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 4BC2D3F3D6; Tue, 17 Jan 2017 02:03:54 -0800 (PST) Date: Tue, 17 Jan 2017 10:04:00 -0000 From: Dave Martin To: Yao Qi Cc: 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: <20170117100349.GR3699@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: <20170116151156.GI28060@E107787-LIN> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2017-01/txt/msg00026.txt.bz2 On Mon, Jan 16, 2017 at 03:11:56PM +0000, Yao Qi wrote: > On 17-01-16 13:32:31, Dave Martin wrote: > > On Mon, Jan 16, 2017 at 12:20:38PM +0000, Yao Qi wrote: > > > On 17-01-12 11:26:07, Dave Martin wrote: > > > > This patch adds support for manipulating a task's vector length at > > > > runtime via ptrace. > > > > > > > > > > I hope kernel doesn't provide such interface to ptracer to change vector > > > length. > > > > It does, with this patch, beacuse... > > > > > The vector length is sort of a read-only property of thread/process/ > > > program to debugger, unless we really have a clear requirement to modify > > > vector length in debugging. I may miss something because I haven't debug > > > SVE code yet. > > > > ...the vector length is no longer read-only for the task, thanks to > > the new prctls(). > > What I meant "read-only" is that debugger can't change it, while the program > itself can change it via prctl(). I see. > > > > This does add complexity, but I figured that any programmer's model > > state that the thread can modify for itself should be modifiable by the > > debugger, if for no other reason than the user may want to experiment to > > see what happens. Without a ptrace interface, it would be necessary > > to inject a prctl() call into the target, which is possible but awkward. > > We only need such interface if it is useful, see more below. > > Suppose it is useful to change vector length through ptrace, we should align > ptrace interface to prctl() as much as possible. Looks that both prctl > change and ptrace change can go through sve_set_vector_length, easy to keep > two consistent. > > > > > 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. > > > > > Access via ptrace also allows things like trapping on exec, fork or > > clone and changing the vector length for the new process or thread > > before it starts to run. I'm guessing here, but such a scenario seems > > legitimate (?) > > > > Yes, these cases are valid, but the usefulness is still questionable to > me. I just doubt that SVE developers do need to change vector length > when they are debugging code. Note that it is not my strong objection > to this patch, if kernel people believe this is useful, I am fine with > it. That's fair. I'll leave the patch there for now and see if anyone else has a comment to make, but it could be removed without affecting anything else. Are there situations in which injecting a function call into the target won't work, i.e., where we couldn't do: set prctl(...) ? Using the prctl interface this way, it would also be preferable to refer to the #defines by name. Cheers ---Dave