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

Maciej W. Rozycki
2023-08-09T23:09:51Z

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