Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Greg Savin via Gdb-patches <gdb-patches@sourceware.org>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: gdb-patches@sourceware.org, Andrew Burgess <andrew.burgess@embecosm.com>
Subject: Re: [PATCH] RISC-V: support for vector register accesses via ptrace() in RISC-V Linux native
Date: Wed, 9 Aug 2023 11:11:44 -0700	[thread overview]
Message-ID: <CADdv1FqjLPZ-eWOKPv0uZxF-u-SYjn0WJGr3KWW9H06-O0L35w@mail.gmail.com> (raw)
In-Reply-To: <alpine.DEB.2.21.2308091008500.25915@angie.orcam.me.uk>

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
>

  reply	other threads:[~2023-08-09 18:12 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-03 23:01 Greg Savin via Gdb-patches
2023-08-04  0:21 ` John Baldwin
2023-08-08 22:50   ` [PATCH v2] " Greg Savin via Gdb-patches
2023-08-11 14:27     ` Andrew Burgess via Gdb-patches
2023-08-11 16:41       ` Greg Savin via Gdb-patches
2023-08-09  9:21 ` [PATCH] " Maciej W. Rozycki
2023-08-09 18:11   ` Greg Savin via Gdb-patches [this message]
2023-08-09 23:09     ` Maciej W. Rozycki
2023-08-10 10:35       ` Andy Chiu via Gdb-patches
2023-08-10 11:40         ` Maciej W. Rozycki
2023-08-10 13:55           ` Maciej W. Rozycki
2023-08-10 17:23             ` Andy Chiu via Gdb-patches
2023-08-10 21:08               ` Palmer Dabbelt
2023-08-10 21:21               ` Maciej W. Rozycki
2023-08-11 11:28                 ` Andy Chiu via Gdb-patches
2023-08-10 14:05           ` Andy Chiu via Gdb-patches
2023-08-10 20:51             ` Maciej W. Rozycki
2025-07-30 10:52 Sameer Natu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADdv1FqjLPZ-eWOKPv0uZxF-u-SYjn0WJGr3KWW9H06-O0L35w@mail.gmail.com \
    --to=gdb-patches@sourceware.org \
    --cc=andrew.burgess@embecosm.com \
    --cc=greg.savin@sifive.com \
    --cc=macro@orcam.me.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox