Re: [PATCH] RISC-V: support for vector register accesses via ptrace() in RISC-V Linux native

From: Andy Chiu <andy.chiu@sifive.com>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Greg Savin <greg.savin@sifive.com>,
	Greentime Hu <greentime.hu@sifive.com>,
	linux-riscv@lists.infradead.org, gdb-patches@sourceware.org,
	Andrew Burgess <andrew.burgess@embecosm.com>
Subject: Re: [PATCH] RISC-V: support for vector register accesses via ptrace() in RISC-V Linux native
Date: Thu, 10 Aug 2023 10:35:11 +0000	[thread overview]
Message-ID: <20230810103510.GA2509@hsinchu26> (raw)
In-Reply-To: <alpine.DEB.2.21.2308092247280.25915@angie.orcam.me.uk>

On Thu, Aug 10, 2023 at 12:09:17AM +0100, Maciej W. Rozycki wrote:
> 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.

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.

> 
>  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

Andy

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv