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

Greg Savin via Gdb-patches
2023-08-09T18:12:23Z

Hi Maciej,

The SIGILL guard is being used as a wrapper around determination of the
VLENB CSR, which is not part of the ptrace() payload for vector registers,
at least as it exists at head-of-tree Linux kernel. GDB or gdbserver
needs to know VLENB in order to construct the architectural feature
metadata that reports an accurate width for the vector registers. If not
for the VLENB determination specifically, and the lack of this information
via ptrace(), then there would be no motivation for executing a vector
instruction directly. It's a workaround, basically. I guess I could
inquire in Linux kernel land regarding whether the NT_RISCV_VECTOR ptrace()
payload could be enhanced to provide VLENB.

Regards,
Greg

On Wed, Aug 9, 2023 at 2:21 AM Maciej W. Rozycki <macro@orcam.me.uk> wrote:

> On Thu, 3 Aug 2023, Greg Savin via Gdb-patches wrote:
>
> > +static unsigned long
> > +safe_read_vlenb ()
> > +{
> > + /* Surrounding the attempt here to read VLENB CSR to have a signal
> handler set up
> > + to trap illegal instruction condition (SIGILL), and if a trap
> happens during this call,
> > + get control back within this function and return 0 in that case.
> > + */
> > + unsigned long vlenb = 0;
> > + struct sigaction our_action = { 0 };
> > + struct sigaction original_action;
> > + int sysresult;
> > +
> > +
> > + our_action.sa_handler = sigill_guard;
> > +
> > + sysresult = sigaction (SIGILL, &our_action, &original_action);
> > + if (sysresult != 0)
> > + {
> > + perror
> > + ("Error installing temporary SIGILL handler in safe_read_vlenb()");
> > + }
> > +
> > + if (SIGSETJMP (sigill_guard_jmp_buf, 1) == 0)
> > + {
> > + asm ("csrr %0, vlenb":"=r" (vlenb));
> > + }
> > + else
> > + {
> > + /* Must've generated an illegal instruction condition; we'll
> figure this means
> > + no vector unit is present */
> > + vlenb = 0;
> > + }
>
> I find it weird that you trap SIGILL and try to execute a vector
> instruction in the debugger to determine whether `ptrace' can be used to
> access the vector state in the debuggee. Why?
>
> The usual way is to try to use `ptrace' itself to determine whether the
> OS has support for it in the first place and then can access the vector
> state. You can then return the contents of the register retrieved if
> successful.
>
> Maciej
>