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

[Andy Chiu]

On Thu, Aug 10, 2023 at 9:55 PM Maciej W. Rozycki <macro at orcam.me.uk> wrote:
>
> On Thu, 10 Aug 2023, Maciej W. Rozycki wrote:
>
> > > 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.
> >
> >  No, how do you expect it to work with a core dump (that can be examined
> > on a different system, or with a cross-debugger)?  You need to change the
> > API I'm afraid; it's unusable anyway.  It's a pity the toolchain community
> > wasn't consulted if you weren't sure how to design the interface.  Better
> > yet it would have been to implement the GDB side before the kernel part
> > has been committed.

I just took some look into the code and here is what I came up with.
Actually, you know VLENB in a core dump file. The size of
NT_RISCV_VECTOR in a core dump file just equals sizeof(struct
__riscv_v_ext_state), which is 40B, plus VLENB * 32. So, the debugger
can actually calculate VLENB and resolve placement of V registers by
subtracting 40 from the size of NT_RISCV_VECTOR in a core dump file.

On the other hand, ptrace is not so lucky. The kernel will return the
min of either user specified size or the maximum Vector size. It is
still safe if we consider SMP with the same VLENB across cores though,
which is an assumption made on Linux. We just need a way to get VLENB
on the system.

>
>  NB since this stuff went in with v6.5-rc1 and v6.5 hasn't been released
> you can still back out the problematic change as no one is expected to use
> RC stuff in production.  Alternatively you can redefine NT_RISCV_VECTOR
> for a corrected ABI, but I think it shouldn't be necessary.  You just need
> to act quickly as I guess there may be 1-2 further v6.5 RCs only and you
> have to get with that to Linus right away.  We can have a release or two
> without NT_RISCV_VECTOR support for the otherwise included vector stuff,
> it shouldn't be a big deal.  There just won't be support for the debug
> API.
>
>  CC-ing Linux ptrace/RISC-V maintainers now to bring their attention.
>
>   Maciej

Thanks,
Andy