From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=o5WK=D2=orcam.me.uk=macro@sourceware.org>
Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34])
	by sourceware.org (Postfix) with ESMTP id 3A9503858D20
	for <gdb-patches@sourceware.org>; Wed,  9 Aug 2023 09:21:01 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3A9503858D20
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk
Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk
Received: by angie.orcam.me.uk (Postfix, from userid 500)
	id A4CF19200C1; Wed,  9 Aug 2023 11:21:00 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
	by angie.orcam.me.uk (Postfix) with ESMTP id 9DBBE9200BB;
	Wed,  9 Aug 2023 10:21:00 +0100 (BST)
Date: Wed, 9 Aug 2023 10:21:00 +0100 (BST)
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: Greg Savin <greg.savin@sifive.com>
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
In-Reply-To: <20230803230110.904724-1-greg.savin@sifive.com>
Message-ID: <alpine.DEB.2.21.2308091008500.25915@angie.orcam.me.uk>
References: <20230803230110.904724-1-greg.savin@sifive.com>
User-Agent: Alpine 2.21 (DEB 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-Spam-Status: No, score=-1163.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_INFOUSMEBIZ,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org
List-Id: <gdb-patches.sourceware.org>

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