From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 8FFOAavM1GS1+jwAWB0awg (envelope-from ) for ; Thu, 10 Aug 2023 07:40:27 -0400 Received: by simark.ca (Postfix, from userid 112) id 0357E1E0BB; Thu, 10 Aug 2023 07:40:27 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id EB5F91E028 for ; Thu, 10 Aug 2023 07:40:24 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9A0E7385559F for ; Thu, 10 Aug 2023 11:40:24 +0000 (GMT) Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id 2C8323856943 for ; Thu, 10 Aug 2023 11:40:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2C8323856943 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk Received: by angie.orcam.me.uk (Postfix, from userid 500) id 85D4D9200C1; Thu, 10 Aug 2023 13:40:12 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id 7F6179200BF; Thu, 10 Aug 2023 12:40:12 +0100 (BST) Date: Thu, 10 Aug 2023 12:40:12 +0100 (BST) From: "Maciej W. Rozycki" To: Andy Chiu cc: Greg Savin , Greentime Hu , linux-riscv@lists.infradead.org, gdb-patches@sourceware.org, Andrew Burgess Subject: Re: [PATCH] RISC-V: support for vector register accesses via ptrace() in RISC-V Linux native In-Reply-To: <20230810103510.GA2509@hsinchu26> Message-ID: References: <20230803230110.904724-1-greg.savin@sifive.com> <20230810103510.GA2509@hsinchu26> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-1163.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_INFOUSMEBIZ, KAM_LAZY_DOMAIN_SECURITY, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On Thu, 10 Aug 2023, Andy Chiu wrote: > > > The SIGILL guard is being used as a wrapper around determination of the > > > VLENB CSR, which is not part of the ptrace() payload for vector registers, > > > at least as it exists at head-of-tree Linux kernel. GDB or gdbserver > > > needs to know VLENB in order to construct the architectural feature > > > metadata that reports an accurate width for the vector registers. If not > > > for the VLENB determination specifically, and the lack of this information > > > via ptrace(), then there would be no motivation for executing a vector > > > instruction directly. It's a workaround, basically. I guess I could > > > inquire in Linux kernel land regarding whether the NT_RISCV_VECTOR ptrace() > > > payload could be enhanced to provide VLENB. > > > > I think the kernel interface needs to be clarified first, before we can > > proceed with the tools side. > > > > I can see the vector state is carried in a REGSET_V regset, which in turn > > corresponds to an NT_RISCV_VECTOR core file note. I can see that besides > > the vector data registers only the VSTART, VL, VTYPE, and VCSR vector CSRs > > are provided in that regset, and that vector data registers are assigned > > a contiguous space of (32 * RISCV_MAX_VLENB) bytes rather than individual > > slots. > > > > So how are we supposed to determine the width of the vector registers > > recorded in a core file? I'd say the RISC-V/Linux kernel regset API is > > incomplete. > > Does it make sense to you if we encapsulate this with a hwprobe syscall? > e.g provide a hwprobe entry to get system's VLENB. We will have to > increase and rearrange the buffer for NT_RISCV_VECTOR if we want to use > ptrace as the entry point for this purpose. I am not very sure if it'd be > too late to do though. No, how do you expect it to work with a core dump (that can be examined on a different system, or with a cross-debugger)? You need to change the API I'm afraid; it's unusable anyway. It's a pity the toolchain community wasn't consulted if you weren't sure how to design the interface. Better yet it would have been to implement the GDB side before the kernel part has been committed. Maciej