[PATCH v2 1/3] RISC-V/Linux/native: Determine FLEN dynamically

["Maciej W. Rozycki" <macro@wdc.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 19286 bytes --]

Fix RISC-V native Linux support to handle a 64-bit FPU (FLEN == 64) with 
both RV32 and RV64 systems, which is a part of the current Linux ABI for 
hard-float systems, rather than assuming that (FLEN == XLEN) in target 
description determination and that (FLEN == 64) in register access.

We can do better however and not rely on any particular value of FLEN 
and probe for it dynamically, by observing that the PTRACE_GETREGSET 
ptrace(2) call will only accept an exact regset size, and that will 
reflect FLEN.  Therefore iterate over the call in target description 
determination with a geometrically increasing regset size until a match 
is marked by a successful ptrace(2) call completion or we run beyond the 
maximum size we can support.

Update register accessors accordingly, using FLEN determined to size the 
buffer used for NT_PRSTATUS requests and then to exchange data with the 
regcache.

Also handle a glibc bug where ELF_NFPREG is defined in terms of NFPREG, 
however NFPREG is nowhere defined.

	gdb/
	* riscv-linux-nat.c [!NFPREG] (NFPREG): New macro.
	(supply_fpregset_regnum, fill_fpregset): Handle regset buffer 
	offsets according to FLEN determined.
	(riscv_linux_nat_target::read_description): Determine FLEN 
	dynamically.
	(riscv_linux_nat_target::fetch_registers): Size regset buffer 
	according to FLEN determined.
	(riscv_linux_nat_target::store_registers): Likewise.
---
Hi,

 I'm not particularly happy with the lengthy lines in `fill_fpregset' and 
`supply_fpregset_regnum' causing multiple wrapping and deep indentation, 
but technically there is nothing wrong with it, so I'll leave it to a 
later clean-up.

  Maciej

Changes from v1:

- Also set the size of the regset buffer dynamically in 
  `riscv_linux_nat_target::fetch_registers' and 
  `riscv_linux_nat_target::store_registers', and update `fill_fpregset' 
  and `supply_fpregset_regnum' accordingly.
---
 gdb/riscv-linux-nat.c |   97 ++++++++++++++++++++++++++++++++++++++------------
 1 file changed, 75 insertions(+), 22 deletions(-)

gdb-riscv-linux-nat-flen.diff
Index: binutils-gdb/gdb/riscv-linux-nat.c
===================================================================
--- binutils-gdb.orig/gdb/riscv-linux-nat.c
+++ binutils-gdb/gdb/riscv-linux-nat.c
@@ -28,6 +28,11 @@
 
 #include <sys/ptrace.h>
 
+/* Work around glibc header breakage causing ELF_NFPREG not to be usable.  */
+#ifndef NFPREG
+# define NFPREG 33
+#endif
+
 /* RISC-V Linux native additions to the default linux support.  */
 
 class riscv_linux_nat_target final : public linux_nat_target
@@ -88,21 +93,33 @@ static void
 supply_fpregset_regnum (struct regcache *regcache, const prfpregset_t *fpregs,
 			int regnum)
 {
+  int flen = register_size (regcache->arch (), RISCV_FIRST_FP_REGNUM);
+  union
+    {
+      const prfpregset_t *fpregs;
+      const gdb_byte *buf;
+    }
+  fpbuf = { .fpregs = fpregs };
   int i;
 
   if (regnum == -1)
     {
       /* We only support the FP registers and FCSR here.  */
       for (i = RISCV_FIRST_FP_REGNUM; i <= RISCV_LAST_FP_REGNUM; i++)
-	regcache->raw_supply (i, &fpregs->__d.__f[i - RISCV_FIRST_FP_REGNUM]);
+	regcache->raw_supply (i,
+			      fpbuf.buf + flen * (i - RISCV_FIRST_FP_REGNUM));
 
-      regcache->raw_supply (RISCV_CSR_FCSR_REGNUM, &fpregs->__d.__fcsr);
+      regcache->raw_supply (RISCV_CSR_FCSR_REGNUM,
+			    fpbuf.buf + flen * (RISCV_LAST_FP_REGNUM
+						- RISCV_FIRST_FP_REGNUM + 1));
     }
   else if (regnum >= RISCV_FIRST_FP_REGNUM && regnum <= RISCV_LAST_FP_REGNUM)
     regcache->raw_supply (regnum,
-			  &fpregs->__d.__f[regnum - RISCV_FIRST_FP_REGNUM]);
+			  fpbuf.buf + flen * (regnum - RISCV_FIRST_FP_REGNUM));
   else if (regnum == RISCV_CSR_FCSR_REGNUM)
-    regcache->raw_supply (RISCV_CSR_FCSR_REGNUM, &fpregs->__d.__fcsr);
+    regcache->raw_supply (RISCV_CSR_FCSR_REGNUM,
+			  fpbuf.buf + flen * (RISCV_LAST_FP_REGNUM
+					      - RISCV_FIRST_FP_REGNUM + 1));
 }
 
 /* Copy all floating point registers from regset FPREGS into REGCACHE.  */
@@ -145,19 +162,33 @@ void
 fill_fpregset (const struct regcache *regcache, prfpregset_t *fpregs,
 	       int regnum)
 {
+  int flen = register_size (regcache->arch (), RISCV_FIRST_FP_REGNUM);
+  union
+    {
+      prfpregset_t *fpregs;
+      gdb_byte *buf;
+    }
+  fpbuf = { .fpregs = fpregs };
+
   if (regnum == -1)
     {
       /* We only support the FP registers and FCSR here.  */
       for (int i = RISCV_FIRST_FP_REGNUM; i <= RISCV_LAST_FP_REGNUM; i++)
-	regcache->raw_collect (i, &fpregs->__d.__f[i - RISCV_FIRST_FP_REGNUM]);
+	regcache->raw_collect (i,
+			       fpbuf.buf + flen * (i - RISCV_FIRST_FP_REGNUM));
 
-      regcache->raw_collect (RISCV_CSR_FCSR_REGNUM, &fpregs->__d.__fcsr);
+      regcache->raw_collect (RISCV_CSR_FCSR_REGNUM,
+			     fpbuf.buf + flen * (RISCV_LAST_FP_REGNUM
+						 - RISCV_FIRST_FP_REGNUM + 1));
     }
   else if (regnum >= RISCV_FIRST_FP_REGNUM && regnum <= RISCV_LAST_FP_REGNUM)
     regcache->raw_collect (regnum,
-			   &fpregs->__d.__f[regnum - RISCV_FIRST_FP_REGNUM]);
+			   fpbuf.buf + flen * (regnum
+					       - RISCV_FIRST_FP_REGNUM));
   else if (regnum == RISCV_CSR_FCSR_REGNUM)
-    regcache->raw_collect (RISCV_CSR_FCSR_REGNUM, &fpregs->__d.__fcsr);
+    regcache->raw_collect (RISCV_CSR_FCSR_REGNUM,
+			   fpbuf.buf + flen * (RISCV_LAST_FP_REGNUM
+					       - RISCV_FIRST_FP_REGNUM + 1));
 }
 
 /* Return a target description for the current target.  */
@@ -166,8 +197,8 @@ const struct target_desc *
 riscv_linux_nat_target::read_description ()
 {
   struct riscv_gdbarch_features features;
-  struct iovec iov;
   elf_fpregset_t regs;
+  int flen;
   int tid;
 
   /* Figuring out xlen is easy.  */
@@ -175,19 +206,39 @@ riscv_linux_nat_target::read_description
 
   tid = inferior_ptid.lwp ();
 
-  iov.iov_base = &regs;
-  iov.iov_len = sizeof (regs);
+  /* Start with no f-registers.  */
+  features.flen = 0;
 
-  /* Can we fetch the f-registers?  */
-  if (ptrace (PTRACE_GETREGSET, tid, NT_FPREGSET,
-	      (PTRACE_TYPE_ARG3) &iov) == -1)
-    features.flen = 0;		/* No f-registers.  */
-  else
+  /* How much worth of f-registers can we fetch if any?  */
+  for (flen = sizeof (regs.__f.__f[0]); ; flen *= 2)
     {
-      /* TODO: We need a way to figure out the actual length of the
-	 f-registers.  We could have 64-bit x-registers, with 32-bit
-	 f-registers.  For now, just assumed xlen and flen match.  */
-      features.flen = features.xlen;
+      size_t regset_size;
+      struct iovec iov;
+
+      /* Regsets have a uniform slot size, so we count FSCR like an FGR.  */
+      regset_size = ELF_NFPREG * flen;
+      if (regset_size > sizeof (regs))
+	break;
+
+      iov.iov_base = &regs;
+      iov.iov_len = regset_size;
+      if (ptrace (PTRACE_GETREGSET, tid, NT_FPREGSET,
+		  (PTRACE_TYPE_ARG3) &iov) == -1)
+	{
+	  switch (errno)
+	    {
+	    case EINVAL:
+	      continue;
+	    case EIO:
+	      break;
+	    default:
+	      perror_with_name (_("Couldn't get registers"));
+	      break;
+	    }
+	}
+      else
+	features.flen = flen;
+      break;
     }
 
   return riscv_create_target_description (features);
@@ -228,7 +279,8 @@ riscv_linux_nat_target::fetch_registers
       elf_fpregset_t regs;
 
       iov.iov_base = &regs;
-      iov.iov_len = sizeof (regs);
+      iov.iov_len = ELF_NFPREG * register_size (regcache->arch (),
+						RISCV_FIRST_FP_REGNUM);
 
       if (ptrace (PTRACE_GETREGSET, tid, NT_FPREGSET,
 		  (PTRACE_TYPE_ARG3) &iov) == -1)
@@ -289,7 +341,8 @@ riscv_linux_nat_target::store_registers
       elf_fpregset_t regs;
 
       iov.iov_base = &regs;
-      iov.iov_len = sizeof (regs);
+      iov.iov_len = ELF_NFPREG * register_size (regcache->arch (),
+						RISCV_FIRST_FP_REGNUM);
 
       if (ptrace (PTRACE_GETREGSET, tid, NT_FPREGSET,
 		  (PTRACE_TYPE_ARG3) &iov) == -1)
From gdb-patches-return-163631-listarch-gdb-patches=sources.redhat.com@sourceware.org Wed Jan 29 18:13:14 2020
Return-Path: <gdb-patches-return-163631-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb-patches@sources.redhat.com
Received: (qmail 6930 invoked by alias); 29 Jan 2020 18:13:13 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Delivered-To: mailing list gdb-patches@sourceware.org
Received: (qmail 6918 invoked by uid 89); 29 Jan 2020 18:13:13 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 testsºYES_00 autolearn=ham version=3.3.1 spammy=risc-v, RISC-V, H*r:353
X-HELO: esa1.hgst.iphmx.com
Received: from esa1.hgst.iphmx.com (HELO esa1.hgst.iphmx.com) (68.232.141.245) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Jan 2020 18:13:12 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;  d=wdc.com; i=@wdc.com; q=dns/txt; s=dkim.wdc.com;  t\x1580321591; x\x1611857591;  h=from:to:cc:subject:date:message-id:content-id:   content-transfer-encoding:mime-version;  bh=V0fDku4qVhprqEBjmLC/qqORct/mnq8LGIOb5D+vihI=;  b=eriRMQcoadmUYHV7DQulBdSaAVN1YuTNN4wLkb4s+jOvC4gfsi1TvvcP   XmLI+i5HMzQplGdPKrgMtF5bn1mVXoaDSTZuI9lN9xJ8hEhJm4R+SyoEX   GOPRmb3joTcOqwlZlXPd3G5K7r8n/S72fQfAMbAG3VgKqBHU+dzaMOC4B   VJ1I361K/wtS1q/P+y2QxziwQghilhRdC8SBX/Sn/h89M3ohaeRnntMuu   lcI8CUsjSpwGGmkubywXJcgkdOEcORKzwcO6FTcXGwKhHR8ZPjLVf+ofZ   TG0MKG10rJGavXtRSP9NxEBx+xWa7fAklvwL2BHSbSmnWXxsDhwV0R1rS   w==;
IronPort-SDR: lZLF5kYt8jf1Q/olTuXaweSXzgapGanUSiIanTulLaXB11B19vKt5a4Dqr/ZQB5sH6/jiHaEFh 0fgZXM2aVvxRYi8BiMQAPYC2CA/EQSZAv7I8ouHUVMklkifCvkvThGxWVuJbs8VVi3yt3BxLrX Wloir2wb3evwsYaP5F/yqYlNeXS+Le44aXPGSn+tYNv45NAQP4rjyskTkb4mQx0ZkYUMFALe82 q4G2pWoOt84I57Ee/Zj8/k0u+WpsWgw6OH2GXen0IuK4CPFxjK14hEU3C2bdrfay5iNuPkDsbD FkEReceived: from mail-dm6nam11lp2171.outbound.protection.outlook.com (HELO NAM11-DM6-obe.outbound.protection.outlook.com) ([104.47.57.171])  by ob1.hgst.iphmx.com with ESMTP; 30 Jan 2020 02:12:48 +0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JS1jWF09BSiGWsdGTsEsLcpHU3BTf2pLWDN8Rb8XYWQBHdutD5jSbH7bPNA7AN+wZQr5/dar9ABAJLjVvhTAO7A+PqHF0u8WeIE5Nhu0BOeNMdM5ed06ApBuL/9nN/3tEETAogXtwhR1+NvxvZHH2fCHKwozrU4nG7JhsHf/JrMQYKB6gqBDRxVa5reyey3zrJJB7N/C0rz716Wqy3BPmwep0rDAIf3p2B5EiT9JiksLYYi4tXThzdoQnkpwYjdAIoiGNRbMsQbSvag19DYK3gbuJlwnmjJGZr6RH/+TbqAJXDorNejvwVuRZQlWYd+kpOLTAxMGTA2/TJ9JqGXORA=ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DhpHg87sB/bhmq4P23+YyDtIjr/qf6U/Hv/WsZPBfzg=; b=hbzdVVDGj2Rwk4rJe5HMaC0xNPf3V2edJ/rZV+g/tA7NTOLg0170eC2wV/DIMxthRk0G7Egqni/nRhyH6Zi2ne8aY7WYcqGeHC9a+1b/ZnoWIF3BjvDOZX+T4dRJXdrZ/gK+7VfVLt8lgXkPLWdnKJRGQrEIIZ8BXhitlz1OHkLAHtC98Mn8CrERx+lQvXmnW6spw8alJL8BKtcWZOe6x/KflQfbfmqJ4mUYPqUSUnb3BA8gwVqDVH79FC6mQXbCCdc3zuSHiKZdQZsT1tx6JzmuX/znFltWEbEcKry1vS3EU8k4RsYBfH5sjn2wkPRCdpHHsC5t0+aWvhshjKPZww=ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=wdc.com; dmarc=pass action=none header.from=wdc.com; dkim=pass header.d=wdc.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sharedspace.onmicrosoft.com; s=selector2-sharedspace-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DhpHg87sB/bhmq4P23+YyDtIjr/qf6U/Hv/WsZPBfzg=; b=kJehB1m2+Vd1Au7dZpmucC8PnmJpUC9W6UEU/M9pgQpesbyg4zmaVlu5Wij3Od91wpgxkCUh/SIdhvMXvLI2gGzNDe0UOA/2mZ86EYSPi6sotsCsKz0FzAN1m7n8JTYm7CdChcWvFEDnVbXVA78/tvzy7qcOm/8S+fv7TiibWUcReceived: from BY5PR04MB6980.namprd04.prod.outlook.com (10.186.134.11) by BY5PR04MB6328.namprd04.prod.outlook.com (52.133.250.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.20; Wed, 29 Jan 2020 18:12:46 +0000
Received: from BY5PR04MB6980.namprd04.prod.outlook.com ([fe80::d068:7819:b5cf:353]) by BY5PR04MB6980.namprd04.prod.outlook.com ([fe80::d068:7819:b5cf:353%5]) with mapi id 15.20.2665.027; Wed, 29 Jan 2020 18:12:46 +0000
From: "Maciej W. Rozycki" <macro@wdc.com>
To: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
CC: Jim Wilson <jimw@sifive.com>, Andrew Burgess	<andrew.burgess@embecosm.com>, Palmer Dabbelt <palmer@dabbelt.com>, Tom Tromey <tom@tromey.com>, "guoren@kernel.org" <guoren@kernel.org>,	"lifang_xia@c-sky.com" <lifang_xia@c-sky.com>, "yunhai_shang@c-sky.com"	<yunhai_shang@c-sky.com>, "jiangshuai_li@c-sky.com" <jiangshuai_li@c-sky.com>
Subject: [PATCH v2 0/3] RISC-V/Linux `gdbserver' support and associated fixes
Date: Wed, 29 Jan 2020 18:13:00 -0000
Message-ID: <alpine.LFD.2.21.2001291207310.14118@redsun52.ssa.fujisawa.hgst.com>
authentication-results: spf=none (sender IP is ) smtp.mailfrom=macro@wdc.com;
x-ms-exchange-transport-forked: True
wdcipoutbound: EOP-TRUE
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-messagedata: HbeNfgmnV/RYsJA78nlul2JgN8s6KwS+yOA/oZ0vuIIW5QZRs4gQKryP8pUOXL5mYclVkA9PqUSCgjZklmIbF08oRq4fIbcX8g2hGZb7DDsIscZ7AzDL6pCp4bCB+7Uh3gLeG10+G5CsXShzn9jWbg=Content-Type: text/plain; charset="us-ascii"
Content-ID: <FA09A39B9A2E0D4BA21D0F1D3554DE05@namprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: WdWsvSKVUdlbSoZh8nb30wFejKldGBsOskj/fXUNBXd6QaxsrGAEmSMNdbJ5x6fK
X-SW-Source: 2020-01/txt/msg00945.txt.bz2
Content-length: 978

Hi,

 This is v2 of my RISC-V/Linux `gdbserver' support proposal.

 As discussed with the original series I have now factored out large parts 
of `riscv_linux_nat_target::read_description' from riscv-linux-nat.c.  
This is change 2/3 in this series.

 In the course of that effort I have realised other parts of native 
support require adjustment as they access the FP regset as 64-bit even if 
previously assumed (and now detected as) 32-bit.  The relevant fix has 
been integrated into change 1/3.

 Also `gdbserver' itself requires a similar update (which I might have 
realised and forgotten about since Nov), which I have now integrated into 
change 3/3.

 There have been no regressions in native `riscv64-linux-gnu' testing and 
remote `gdbserver' test results are the same as previously (barring the 
usual gdb.threads/ fluctuations).  I think all the changes are ready to go 
in now.

 As usually see individual changes for details.

  Maciej
From gdb-patches-return-163633-listarch-gdb-patches=sources.redhat.com@sourceware.org Wed Jan 29 18:13:40 2020
Return-Path: <gdb-patches-return-163633-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb-patches@sources.redhat.com
Received: (qmail 9350 invoked by alias); 29 Jan 2020 18:13:39 -0000
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
Delivered-To: mailing list gdb-patches@sourceware.org
Received: (qmail 9317 invoked by uid 89); 29 Jan 2020 18:13:38 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-26.9 required=5.0 testsºYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammyX-HELO: us-smtp-delivery-1.mimecast.com
Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Jan 2020 18:13:37 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com;	s=mimecast20190719; t\x1580321615;	h=from:from:reply-to:subject:subject:date:date:message-id:message-id:	 to:to:cc:cc:mime-version:mime-version:content-type:content-type:	 content-transfer-encoding:content-transfer-encoding:	 in-reply-to:in-reply-to:references:references;	bh=GHecUPtFz6vWIkjrOJsujy90lwX8KjDKoL3bsxVCd94=;	b=Gwk+irFF1SfSIr2eHKTYfqQctmp2/ysVjKLLnqMdf2BkAXX3+ua2ZyTUg4u9Iv9HtkK3bd	yP76U9ikVhACpAeUwlURZeq0tboTCDa3iMmAIP9KrOs7usGO+9hKbgdFbu2XjJstkyOZsN	2Ft4W3HAIkJBwUnVSbHbJVoC0SypO5wReceived: from mail-wm1-f69.google.com (mail-wm1-f69.google.com [209.85.128.69]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-180-Nx_j6_u2Nb-JlLV1YBWKCQ-1; Wed, 29 Jan 2020 13:13:26 -0500
Received: by mail-wm1-f69.google.com with SMTP id b202so252938wmb.2        for <gdb-patches@sourceware.org>; Wed, 29 Jan 2020 10:13:26 -0800 (PST)
Return-Path: <palves@redhat.com>
Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b])        by smtp.gmail.com with ESMTPSA id b21sm3283959wmd.37.2020.01.29.10.13.23        (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits\x128/128);        Wed, 29 Jan 2020 10:13:23 -0800 (PST)
Subject: Re: [PATCH] Adjust src-release.sh's getver due to gdbsupport's move to toplevel
To: Sergio Durigan Junior <sergiodj@redhat.com>, GDB Patches <gdb-patches@sourceware.org>
References: <20200128222514.10753-1-sergiodj@redhat.com>
Cc: tom@tromey.com, binutils@sourceware.org
From: Pedro Alves <palves@redhat.com>
Message-ID: <28831a42-3bb1-c232-0d8f-f18c5a4343d5@redhat.com>
Date: Wed, 29 Jan 2020 18:13:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <20200128222514.10753-1-sergiodj@redhat.com>
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-SW-Source: 2020-01/txt/msg00947.txt.bz2
Content-length: 929

On 1/28/20 10:25 PM, Sergio Durigan Junior wrote:

> diff --git a/src-release.sh b/src-release.sh
> index 92e92ac5d7..b3ca5ae137 100755
> --- a/src-release.sh
> +++ b/src-release.sh
> @@ -61,8 +61,8 @@ getver()
>  	$tool/common/create-version.sh $tool 'dummy-host' 'dummy-target' VER.tmp
>  	cat VER.tmp | grep 'version\[\]' | sed 's/.*"\([^"]*\)".*/\1/' | sed 's/-git$//'
>          rm -f VER.tmp
> -    elif test -f $tool/gdbsupport/create-version.sh; then
> -	$tool/gdbsupport/create-version.sh $tool 'dummy-host' 'dummy-target' VER.tmp
> +    elif test -f ./gdbsupport/create-version.sh; then
> +	./gdbsupport/create-version.sh $tool 'dummy-host' 'dummy-target' VER.tmp

It seems like this makes it so that the version.in fallback becomes unreachable.
./gdbsupport/create-version.sh is always going to exist irrespective of what
$tool is.  Maybe it would be better to check that $tool is "gdb" instead.

Thanks,
Pedro Alves