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

["Maciej W. Rozycki" <macro@orcam.me.uk>]

On Fri, 11 Aug 2023, Andy Chiu wrote:

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

 Fair enough, I didn't dive into Linux code deeply enough to figure out 
that the size of an NT_RISCV_VECTOR core file note is indeed dynamically 
calculated.  Most notes are of a fixed size, but we also have generic 
support for variable-size ones in GDB, so handling this case should be 
reasonably straightforward.

 OTOH VLENB is a program-visible register, so I think it will best be 
provided explicitly regardless rather than having to be reconstructed from 
the size of the note; I would find that awkward.

 NB I have been a bit concerned about the unusually huge allocation size 
of 256KiB+ for the register buffer required for ptrace(2), but I guess 
we'll have to live with it, because any solution that makes it dynamic 
would also complicate the interface.  At least we won't waste filesystem 
space for any extraneous allocation in core dumps.

  Maciej