RISC-V Vector Extension Support

[Kirill Radkin <kirill.radkin@syntacore.com>]

Hi Sameer,

My name is Kirill Radkin. Like you, I have been working with my colleagues at Syntacore on RVV
support in GDB. I've attached my patch in other thread
(https://inbox.sourceware.org/gdb-patches/20251107165534.1688124-1-kirill.radkin@syntacore.com/T/#t), 
but I’d like to share some suggestions and possible improvements here.

Here are some of the key differences and improvements in our implementation:

- `create_feature_riscv_vector_from_features`
  In our implementation, this function is called `create_feature_riscv_rvv`.

  1. Vector CSRs are added to `"org.gnu.gdb.riscv.csr"` instead of `"org.gnu.gdb.riscv.vector"`.
     Placing vector CSR registers in this feature is incorrect and breaks compatibility with OpenOCD
     (bare-metal targets), because it requires placing these registers in "org.gnu.gdb.riscv.csr".
  2. Vector register types are represented not only as integer values, but also as floating-point
  values.

- Defining VLENB
  We use the same approach with `asm ("csrr %0, vlenb" : "=r"(vlenb));`, but to guard this
  instruction we rely on the RISC-V hwprobe interface:


  features.vlenb = 0;

  static struct riscv_hwprobe query[] = { { RISCV_HWPROBE_KEY_IMA_EXT_0, 0 } };

  if ((syscall (NR_riscv_hwprobe, query, 1, 0, NULL, 0) == 0)
      && (query[0].value & RISCV_HWPROBE_IMA_V))
    {
      int reg = 0; asm volatile ("csrr %[vlenb], vlenb" : [vlenb] "=r"(reg)); features.vlenb = reg;
    }


- Vector register cache
  Instead of creating a new cache for vector registers, we reuse the existing GDB regcache. Could
  you clarify why you decided to use a separate cache structure?

- Structure for `ptrace` calls (`struct __riscv_vregs`)
  It seems a bit too large (256 KB). We faced the same issue and solved it with:


  struct __riscv_v_regset_state {
    unsigned long vstart; unsigned long vl; unsigned long vtype; unsigned long vcsr; unsigned long
    vlenb; char vreg[];
  };
  

  Later, when using it for `ptrace` (e.g., in `riscv_linux_nat_target::fetch_registers`), we
  determine the vector register size from regcache and allocate only the necessary amount of memory.

- RVV support in gdbserver

  
  { PTRACE_GETREGSET, PTRACE_SETREGSET, NT_RISCV_VECTOR,
    sizeof (struct __riscv_vregs), OPTIONAL_REGS, riscv_fill_vregset, riscv_store_vregset },
  

  If the vector regset is marked as `OPTIONAL_REGS`, we observed a kernel issue 
  (https://lore.kernel.org/linux-riscv/20251007115840.2320557-1-geomatsi@gmail.com/T/#m87442da077efb7b7f6c0ccd3ee69a01f4e06791c): 
  the vector context is not properly initialized until the first vector instruction is executed.
  As a result, when gdbserver tries to fetch the regset (`regsets_fetch_inferior_registers` from
  `gdbserver/linux-low.cc`), it gets `EINVAL` (instead of ENODATA as it should be) from `ptrace` and
  disables the vector regset. To avoid this, we marked it as `EXTENDED_REGS`.

  Another kernel bug we observed is that ptrace can return a zero vlenb in some cases (more info
  about and possible fix posted to linux mailing list here:
  https://lore.kernel.org/linux-riscv/20250821173957.563472-1-geomatsi@gmail.com/T/#u ). To avoid
  this issue, we added a simple workaround in gdbserver/linux-riscv-low.cc:riscv_store_vecregset.

- RVV ABI support
  The main feature I’d like to propose is support for the RVV ABI, enabling GDB to call functions
  with vector arguments (`call`/`print` commands). Key components:

  1. `struct riscv_vector_arg_reg` — tracks available vector registers for function arguments. 
  2. `riscv_assign_vec_reg_location` — determines which registers should hold arguments depending on
  their type.

- Tests
  Our patch also includes test cases for RVV support.

Best regards, Kirill Radkin