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

Maciej W. Rozycki
2023-08-10T21:21:33Z

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