From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id 5895D3858023 for ; Wed, 9 Aug 2023 23:09:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5895D3858023 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 BB8AF9200C1; Thu, 10 Aug 2023 01:09:17 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id B9C2F9200BF; Thu, 10 Aug 2023 00:09:17 +0100 (BST) Date: Thu, 10 Aug 2023 00:09:17 +0100 (BST) From: "Maciej W. Rozycki" To: Greg Savin , Greentime Hu , Andy Chiu cc: 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: Message-ID: References: <20230803230110.904724-1-greg.savin@sifive.com> 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 List-Id: On Wed, 9 Aug 2023, Greg Savin 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. A complete API has to provide `ptrace' and core file access to all the relevant registers (vector registers in this case) that can be accessed by machine instructions by the debuggee. That includes read-only registers, writes to which via `ptrace' will of course be ignored. If a register is a shadow only and can be reconstructed from another, canonical register (e.g. VXRM vs VCSR) then the shadow register can (and best be) omitted of course. Additional artificial OS registers may also have to be provided that reflect the relevant privileged state made available to the debuggee at run time by OS calls such as prctl(2); this for example might be a mode setting which affects the hardware interpretation of a register set that debug tools may need to take into account or the person debugging may want to check or modify (e.g. REGSET_FP_MODE in the MIPS/Linux port). I've added the authors of the Linux kernel code and the RISC-V/Linux mailing list to the list of recipients. Am I missing anything here? Maciej