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

Andy Chiu via Gdb-patches
2023-08-10T10:35:39Z

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