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

[Palmer Dabbelt]

On Thu, 10 Aug 2023 10:23:34 PDT (-0700), andy.chiu at sifive.com wrote:
> 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.

IMO that's the way to go: given that we're still finding breakagaes this 
late in the cycle it's likely we've got others.  Like Maciej said, we 
should have gotten the GDB stuff in along with the Linux stuff to find 
the problems.

So let's just remove the ptrace() and core dump support for vector, it's 
not been released so it's not stable uABI yet.  We'll just get it right 
before committing it, that can be as simple as just one more release.

>>
>>  CC-ing Linux ptrace/RISC-V maintainers now to bring their attention.
>>
>>   Maciej
>
> Thanks,
> Andy