* [PATCH v2 1/3] RISC-V/Linux/native: Determine FLEN dynamically
[not found] <alpine.LFD.2.21.2001291207310.14118@redsun52.ssa.fujisawa.hgst.com>
@ 2020-01-29 18:13 ` Maciej W. Rozycki
2020-01-29 23:26 ` Jim Wilson
2020-01-30 23:19 ` Jim Wilson
2020-01-29 18:14 ` [PATCH v2 2/3] RISC-V/Linux/native: Factor out target description determination Maciej W. Rozycki
[not found] ` <alpine.LFD.2.21.2001291412560.14118@redsun52.ssa.fujisawa.hgst.com>
2 siblings, 2 replies; 10+ messages in thread
From: Maciej W. Rozycki @ 2020-01-29 18:13 UTC (permalink / raw)
To: gdb-patches
Cc: Jim Wilson, Andrew Burgess, Palmer Dabbelt, Tom Tromey, guoren,
lifang_xia, yunhai_shang, jiangshuai_li
[-- 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 = ®s;
- 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 = ®s;
+ 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 = ®s;
- 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 = ®s;
- 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* [PATCH v2 2/3] RISC-V/Linux/native: Factor out target description determination
[not found] <alpine.LFD.2.21.2001291207310.14118@redsun52.ssa.fujisawa.hgst.com>
2020-01-29 18:13 ` [PATCH v2 1/3] RISC-V/Linux/native: Determine FLEN dynamically Maciej W. Rozycki
@ 2020-01-29 18:14 ` Maciej W. Rozycki
2020-01-29 23:39 ` Jim Wilson
[not found] ` <alpine.LFD.2.21.2001291412560.14118@redsun52.ssa.fujisawa.hgst.com>
2 siblings, 1 reply; 10+ messages in thread
From: Maciej W. Rozycki @ 2020-01-29 18:14 UTC (permalink / raw)
To: gdb-patches
Cc: Jim Wilson, Andrew Burgess, Palmer Dabbelt, Tom Tromey, guoren,
lifang_xia, yunhai_shang, jiangshuai_li
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 32919 bytes --]
In preparation for RISC-V/Linux `gdbserver' support factor out parts of
native target description determination code that can be shared between
the programs.
gdb/
* nat/riscv-linux-tdesc.h: New file.
* nat/riscv-linux-tdesc.c: New file, taking code from...
* riscv-linux-nat.c (riscv_linux_nat_target::read_description):
... here.
* configure.nat <linux> <riscv*>: Add nat/riscv-linux-tdesc.o to
NATDEPFILES.
---
New change in v2.
---
gdb/configure.nat | 3 +
gdb/nat/riscv-linux-tdesc.c | 82 ++++++++++++++++++++++++++++++++++++++++++++
gdb/nat/riscv-linux-tdesc.h | 27 ++++++++++++++
gdb/riscv-linux-nat.c | 50 +-------------------------
4 files changed, 114 insertions(+), 48 deletions(-)
gdb-riscv-linux-nat-tdesc.diff
Index: binutils-gdb/gdb/configure.nat
===================================================================
--- binutils-gdb.orig/gdb/configure.nat
+++ binutils-gdb/gdb/configure.nat
@@ -276,7 +276,8 @@ case ${gdb_host} in
;;
riscv*)
# Host: RISC-V, running Linux
- NATDEPFILES="${NATDEPFILES} riscv-linux-nat.o"
+ NATDEPFILES="${NATDEPFILES} riscv-linux-nat.o \
+ nat/riscv-linux-tdesc.o"
;;
s390)
# Host: S390, running Linux
Index: binutils-gdb/gdb/nat/riscv-linux-tdesc.c
===================================================================
--- /dev/null
+++ binutils-gdb/gdb/nat/riscv-linux-tdesc.c
@@ -0,0 +1,82 @@
+/* GNU/Linux/RISC-V native target description support for GDB.
+ Copyright (C) 2020 Free Software Foundation, Inc.
+
+ This file is part of GDB.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+#include "gdbsupport/common-defs.h"
+
+#include "gdb_proc_service.h"
+#include "arch/riscv.h"
+#include "elf/common.h"
+#include "nat/gdb_ptrace.h"
+#include "nat/riscv-linux-tdesc.h"
+
+#include <sys/uio.h>
+
+/* Work around glibc header breakage causing ELF_NFPREG not to be usable. */
+#ifndef NFPREG
+# define NFPREG 33
+#endif
+
+/* Determine XLEN and FLEN and return a corresponding target description. */
+
+const struct target_desc *
+riscv_linux_read_description (int tid)
+{
+ struct riscv_gdbarch_features features;
+ elf_fpregset_t regs;
+ int flen;
+
+ /* Figuring out xlen is easy. */
+ features.xlen = sizeof (elf_greg_t);
+
+ /* Start with no f-registers. */
+ features.flen = 0;
+
+ /* How much worth of f-registers can we fetch if any? */
+ for (flen = sizeof (regs.__f.__f[0]); ; flen *= 2)
+ {
+ 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 = ®s;
+ 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);
+}
Index: binutils-gdb/gdb/nat/riscv-linux-tdesc.h
===================================================================
--- /dev/null
+++ binutils-gdb/gdb/nat/riscv-linux-tdesc.h
@@ -0,0 +1,27 @@
+/* GNU/Linux/RISC-V native target description support for GDB.
+ Copyright (C) 2020 Free Software Foundation, Inc.
+
+ This file is part of GDB.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+#ifndef NAT_RISCV_LINUX_TDESC_H
+#define NAT_RISCV_LINUX_TDESC_H
+
+struct target_desc;
+
+/* Return a target description for the LWP identified by TID. */
+const struct target_desc *riscv_linux_read_description (int tid);
+
+#endif /* NAT_RISCV_LINUX_TDESC_H */
Index: binutils-gdb/gdb/riscv-linux-nat.c
===================================================================
--- binutils-gdb.orig/gdb/riscv-linux-nat.c
+++ binutils-gdb/gdb/riscv-linux-nat.c
@@ -22,10 +22,11 @@
#include "linux-nat.h"
#include "riscv-tdep.h"
#include "inferior.h"
-#include "target-descriptions.h"
#include "elf/common.h"
+#include "nat/riscv-linux-tdesc.h"
+
#include <sys/ptrace.h>
/* Work around glibc header breakage causing ELF_NFPREG not to be usable. */
@@ -196,52 +197,7 @@ fill_fpregset (const struct regcache *re
const struct target_desc *
riscv_linux_nat_target::read_description ()
{
- struct riscv_gdbarch_features features;
- elf_fpregset_t regs;
- int flen;
- int tid;
-
- /* Figuring out xlen is easy. */
- features.xlen = sizeof (elf_greg_t);
-
- tid = inferior_ptid.lwp ();
-
- /* Start with no f-registers. */
- features.flen = 0;
-
- /* How much worth of f-registers can we fetch if any? */
- for (flen = sizeof (regs.__f.__f[0]); ; flen *= 2)
- {
- 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 = ®s;
- 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);
+ return riscv_linux_read_description (inferior_ptid.lwp ());
}
/* Fetch REGNUM (or all registers if REGNUM == -1) from the target
From gdb-patches-return-163635-listarch-gdb-patches=sources.redhat.com@sourceware.org Wed Jan 29 18:14:23 2020
Return-Path: <gdb-patches-return-163635-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb-patches@sources.redhat.com
Received: (qmail 13598 invoked by alias); 29 Jan 2020 18:14:22 -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 13580 invoked by uid 89); 29 Jan 2020 18:14:20 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-9.7 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_ASCII_DIVIDERS,KAM_SHORT autolearn=ham version=3.3.1 spammyúvour
X-HELO: esa4.hgst.iphmx.com
Received: from esa4.hgst.iphmx.com (HELO esa4.hgst.iphmx.com) (216.71.154.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Jan 2020 18:14:17 +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\x1580321657; x\x1611857657; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7MweSfYkzmbR/skPXXZJYmxhgFD+cua6xoMnSj8yskU=; b=b/iWCRJNyUWb8mJ0QSfDIKJhU12n51+Tq838E0myWaBnjxh0TWIGmK0G S8dlPOaMhL2rHh8ZTwLOqQ+4GRuPwXmlfHH1QCwd1KK/YL9S9HcPKhlFj FW7+rJDsp6LkovsybfKDnhGIR772JJXZ47rR7jAd7zlgeYPsMM7GP7Lgr jak0ApA8t1bCkhxb04/cIQxguQVPdX5GiEgMvybSN48a3nrWOTU0sL9xs T8tkEa45HTGxOfsuIpYmes9BjJUMeuRmOziEuwel0yJmozmY5M6YNtIMx o8W6fxwRRhLhlNbGEwWoUvqOVLt+7czwK+WvkS8xpIQvu4yczxeI2hv5l g==;
IronPort-SDR: uiZAcFLC23+uEyO0sszZ72mdImbXKQnVx34DI6mDU8z/KJ4o0YSHlGhLDUFQ2kUeY5Fd9/EjrX y6bJ+P0V4R3AITMN6ufVbrYDLtRUpgxf+CVa2mvHAJk/jiJBik9vOAR81R1iBBVl3iI59J+llx xnp+sjaLk8mEAruR6Vvw+eDOeZ5J6jQ0SsuNhDtF6qmurYVq4JtabEDPFke+5ttm0HOdfqi5n1 t+2eiDZECahelsgk3l3hgrHa9y3qo+A3vIRCKf7Z9dVg7rNOfgjexzMiQfCxtFOaQhSfmAjfgK l9UReceived: from mail-dm6nam11lp2169.outbound.protection.outlook.com (HELO NAM11-DM6-obe.outbound.protection.outlook.com) ([104.47.57.169]) by ob1.hgst.iphmx.com with ESMTP; 30 Jan 2020 02:14:14 +0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QI6dL+g8n42CabSplCgQOhd78Fw/lmdxUID4iJn9uft4J0GFojduX77t61uIGiEMx76zGaqOEctD0c125g4PjLFQ/eVBH1NwFvXI6/e4DpwFUiLedvrQAsGNMByVxSHF+Lmd/T9vwld0+2LnmJouwPDhHHLTMjENP+qOYp7gYbamdVyqdnjfFN1aaQYJrTALC+WMERf4y8/FYLjynTF3yk9+HJnCe9cDIjY8ZtaSu8lq03OXvlDWY1mnu++wldiatRmYvqlh8NVhqQqreGQOy0OHJUYKWN6xH0k/n0/R7ojsRb7HK4gq6yyRVjMsmXTNivZbg+jnbvqKJ/RzxHOafQ=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þlZJrvZNk8BRsSCDWqZI7E8KwUdl1rcdfxYZ9sCAkI=; b=GS94WCRtB+Lf0refhTnF1rgmAEKr2RZrQwkpJB8TBWVdcRCeA5AKjLWJB0bfblRC7oeu2FbqaVDA97IlVn6/w3AZlgOuP8smK3vf+ty3LScwPSAmcBL0zXnI8E6oxBa/5WBfiv+CN4pFZ9TLvx1Pp4xQXGpKDHAj3MtDB0CXzPqtAqZ7+WJuN4ZFjeNCd+x58sugCz55BN1tTSkkrom8SHuC0CDFfkCJPrCMX+pesB1Zqf3h4kna3IWOjLCE3aaA46JLFmCLAk5WS8k1heKyraHGqujsSxpXnf8uBFDuHceyI6fp4hUjT70zJJ31wb7psyJbdZd+2d1m/M/auakt2Q=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þlZJrvZNk8BRsSCDWqZI7E8KwUdl1rcdfxYZ9sCAkI=; b=dj8CMWw1/H6CTFVfs/yM94twGK/I63vhjveptVpglTro0G4AxkxjJM5AYAtWuaW+wV3gU8OIfjf+resykeH17eGCsdBGUR6POgE9PBMgddq7WloMWejIj/xhdXQtlz4Ld4j1hE9R951ey73v6DtEccanzoJUJvQXY75KUbspefAReceived: from BY5PR04MB6980.namprd04.prod.outlook.com (10.186.134.11) by BY5PR04MB6627.namprd04.prod.outlook.com (10.186.135.75) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.19; Wed, 29 Jan 2020 18:14:13 +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:14:13 +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 3/3] gdbserver: Add RISC-V/Linux support
Date: Wed, 29 Jan 2020 18:39:00 -0000
Message-ID: <alpine.LFD.2.21.2001291412560.14118@redsun52.ssa.fujisawa.hgst.com>
References: <alpine.LFD.2.21.2001291207310.14118@redsun52.ssa.fujisawa.hgst.com>
In-Reply-To: <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:9508;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-messagedata: m0s5FNaaiYJ9dfY97RbtegjehGzRNQf2f5dQvKGkNM6ayLPtrTwY93HOMHgj7ShSbTvx0lfF6WXWQN7o6eHjV1547Z2Xf0Y+RLFW+A5Iw38fw48vV9C4kCUzaXkkm5RjjekZTniUE3ag/FNNF8fKdQ=Content-Type: text/plain; charset="us-ascii"
Content-ID: <1853E36718214E458612A102EF14237C@namprd04.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: le0Uq25GeBUgPUNn78ybovZJ7phKmjC9x+rceW9tDHyo03dIFbWuwy7nXkzD5Crh
X-SW-Source: 2020-01/txt/msg00949.txt.bz2
Content-length: 14868
Implement RISC-V/Linux support for both RV64 and RV32 systems, including
XML target description handling based on features determined, GPR and
FPR regset support including dynamic sizing of the latter, and software
breakpoint handling. Define two NT_FPREGSET regsets of a different size
matching the FPR sizes supported for generic `gdbserver' code to pick
from according to what the OS supplies.
Also handle a glibc bug where ELF_NFPREG is defined in terms of NFPREG,
however NFPREG is nowhere defined.
gdb/
* arch/riscv.h (riscv_create_target_description): Remove `const'
qualifier from the return type.
* arch/riscv.c (riscv_create_target_description): Likewise.
* nat/riscv-linux-tdesc.h (riscv_linux_read_description):
Likewise.
* nat/riscv-linux-tdesc.c (riscv_linux_read_description):
Likewise.
* configure.tgt <riscv*-*-linux*>: Set build_gdbserver=yes.
gdb/gdbserver/
* linux-riscv-low.c: New file.
* Makefile.in (SFILES): Add linux-riscv-low.c, arch/riscv.c, and
nat/riscv-linux-tdesc.c.
* configure.srv <riscv*-*-linux*> (srv_tgtobj)
(srv_linux_regsets, srv_linux_usrregs, srv_linux_thread_db):
Define.
---
Changes from v1:
- Make `gdbserver' selected for automatic build in a RISC-V/Linux/native
GDB configuration (thanks, Jim, for pointing this out!).
- Remove most of `riscv_arch_setup' and use `riscv_linux_read_description'
from 2/3 instead.
- Stop using `elf_fpregset_t*' in favour to just a raw `gdb_byte *' buffer
and size the regset according to the FPR size in `riscv_fill_fpregset'
and `riscv_store_fpregset'.
- Define 2 NT_FPREGSET regsets of a different size for generic `gdbserver'
code to pick from according to what the OS supplies.
---
gdb/arch/riscv.c | 2
gdb/arch/riscv.h | 4
gdb/configure.tgt | 1
gdb/gdbserver/Makefile.in | 3
gdb/gdbserver/configure.srv | 7 +
gdb/gdbserver/linux-riscv-low.c | 257 ++++++++++++++++++++++++++++++++++++++++
gdb/nat/riscv-linux-tdesc.c | 2
gdb/nat/riscv-linux-tdesc.h | 2
8 files changed, 273 insertions(+), 5 deletions(-)
gdb-riscv-gdbserver-linux.diff
Index: binutils-gdb/gdb/arch/riscv.c
===================================================================
--- binutils-gdb.orig/gdb/arch/riscv.c
+++ binutils-gdb/gdb/arch/riscv.c
@@ -43,7 +43,7 @@ static std::unordered_map<riscv_gdbarch_
/* See arch/riscv.h. */
-const target_desc *
+target_desc *
riscv_create_target_description (struct riscv_gdbarch_features features)
{
/* Have we seen this feature set before? If we have return the same
Index: binutils-gdb/gdb/arch/riscv.h
===================================================================
--- binutils-gdb.orig/gdb/arch/riscv.h
+++ binutils-gdb/gdb/arch/riscv.h
@@ -69,7 +69,7 @@ struct riscv_gdbarch_features
/* Create and return a target description that is compatible with
FEATURES. */
-const target_desc *riscv_create_target_description
- (struct riscv_gdbarch_features features);
+target_desc *riscv_create_target_description
+ (struct riscv_gdbarch_features features);
#endif /* ARCH_RISCV_H */
Index: binutils-gdb/gdb/configure.tgt
===================================================================
--- binutils-gdb.orig/gdb/configure.tgt
+++ binutils-gdb/gdb/configure.tgt
@@ -553,6 +553,7 @@ riscv*-*-linux*)
# Target: Linux/RISC-V
gdb_target_obs="riscv-linux-tdep.o glibc-tdep.o \
linux-tdep.o solib-svr4.o symfile-mem.o linux-record.o"
+ build_gdbserver=yes
;;
riscv*-*-*)
Index: binutils-gdb/gdb/gdbserver/Makefile.in
===================================================================
--- binutils-gdb.orig/gdb/gdbserver/Makefile.in
+++ binutils-gdb/gdb/gdbserver/Makefile.in
@@ -177,6 +177,7 @@ SFILES = \
$(srcdir)/linux-mips-low.c \
$(srcdir)/linux-nios2-low.c \
$(srcdir)/linux-ppc-low.c \
+ $(srcdir)/linux-riscv-low.c \
$(srcdir)/linux-s390-low.c \
$(srcdir)/linux-sh-low.c \
$(srcdir)/linux-sparc-low.c \
@@ -203,6 +204,7 @@ SFILES = \
$(srcdir)/../arch/arm-get-next-pcs.c \
$(srcdir)/../arch/arm-linux.c \
$(srcdir)/../arch/ppc-linux-common.c \
+ $(srcdir)/../arch/riscv.c \
$(srcdir)/../../gdbsupport/btrace-common.c \
$(srcdir)/../../gdbsupport/buffer.c \
$(srcdir)/../../gdbsupport/cleanups.c \
@@ -236,6 +238,7 @@ SFILES = \
$(srcdir)/../nat/linux-personality.c \
$(srcdir)/../nat/mips-linux-watch.c \
$(srcdir)/../nat/ppc-linux.c \
+ $(srcdir)/../nat/riscv-linux-tdesc.c \
$(srcdir)/../nat/fork-inferior.c \
$(srcdir)/../target/waitstatus.c
Index: binutils-gdb/gdb/gdbserver/configure.srv
===================================================================
--- binutils-gdb.orig/gdb/gdbserver/configure.srv
+++ binutils-gdb/gdb/gdbserver/configure.srv
@@ -267,6 +267,13 @@ case "${target}" in
srv_xmlfiles="${srv_xmlfiles} rs6000/power-fpu.xml"
srv_lynxos=yes
;;
+ riscv*-*-linux*) srv_tgtobj="arch/riscv.o nat/riscv-linux-tdesc.o"
+ srv_tgtobj="${srv_tgtobj} linux-riscv-low.o"
+ srv_tgtobj="${srv_tgtobj} ${srv_linux_obj}"
+ srv_linux_regsets=yes
+ srv_linux_usrregs=yes
+ srv_linux_thread_db=yes
+ ;;
s390*-*-linux*) srv_regobj="s390-linux32.o"
srv_regobj="${srv_regobj} s390-linux32v1.o"
srv_regobj="${srv_regobj} s390-linux32v2.o"
Index: binutils-gdb/gdb/gdbserver/linux-riscv-low.c
===================================================================
--- /dev/null
+++ binutils-gdb/gdb/gdbserver/linux-riscv-low.c
@@ -0,0 +1,257 @@
+/* GNU/Linux/RISC-V specific low level interface, for the remote server
+ for GDB.
+ Copyright (C) 2020 Free Software Foundation, Inc.
+
+ This file is part of GDB.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+#include "server.h"
+
+#include "linux-low.h"
+#include "tdesc.h"
+#include "elf/common.h"
+#include "nat/riscv-linux-tdesc.h"
+#include "opcode/riscv.h"
+
+/* Work around glibc header breakage causing ELF_NFPREG not to be usable. */
+#ifndef NFPREG
+# define NFPREG 33
+#endif
+
+/* Implementation of linux_target_ops method "arch_setup". */
+
+static void
+riscv_arch_setup ()
+{
+ static const char *expedite_regs[] = { "sp", "pc", NULL };
+ target_desc *tdesc;
+
+ tdesc = riscv_linux_read_description (lwpid_of (current_thread));
+ if (!tdesc->expedite_regs)
+ init_target_desc (tdesc, expedite_regs);
+ current_process ()->tdesc = tdesc;
+}
+
+static void
+riscv_fill_gregset (struct regcache *regcache, void *buf)
+{
+ const struct target_desc *tdesc = regcache->tdesc;
+ elf_gregset_t *regset = (elf_gregset_t *) buf;
+ int regno = find_regno (tdesc, "zero");
+ int i;
+
+ collect_register_by_name (regcache, "pc", *regset);
+ for (i = 1; i < ARRAY_SIZE (*regset); i++)
+ collect_register (regcache, regno + i, *regset + i);
+}
+
+static void
+riscv_store_gregset (struct regcache *regcache, const void *buf)
+{
+ const elf_gregset_t *regset = (const elf_gregset_t *) buf;
+ const struct target_desc *tdesc = regcache->tdesc;
+ int regno = find_regno (tdesc, "zero");
+ int i;
+
+ supply_register_by_name (regcache, "pc", *regset);
+ supply_register_zeroed (regcache, regno);
+ for (i = 1; i < ARRAY_SIZE (*regset); i++)
+ supply_register (regcache, regno + i, *regset + i);
+}
+
+static void
+riscv_fill_fpregset (struct regcache *regcache, void *buf)
+{
+ const struct target_desc *tdesc = regcache->tdesc;
+ int regno = find_regno (tdesc, "ft0");
+ int flen = register_size (regcache->tdesc, regno);
+ gdb_byte *regset = (gdb_byte *) buf;
+ int i;
+
+ for (i = 0; i < ELF_NFPREG - 1; i++)
+ collect_register (regcache, regno + i, regset + i * flen);
+ collect_register_by_name (regcache, "fcsr", regset + i * flen);
+}
+
+static void
+riscv_store_fpregset (struct regcache *regcache, const void *buf)
+{
+ const struct target_desc *tdesc = regcache->tdesc;
+ int regno = find_regno (tdesc, "ft0");
+ int flen = register_size (regcache->tdesc, regno);
+ const gdb_byte *regset = (const gdb_byte *) buf;
+ int i;
+
+ for (i = 0; i < ELF_NFPREG - 1; i++)
+ supply_register (regcache, regno + i, regset + i * flen);
+ supply_register_by_name (regcache, "fcsr", regset + i * flen);
+}
+
+static struct regset_info riscv_regsets[] = {
+ { PTRACE_GETREGSET, PTRACE_SETREGSET, NT_PRSTATUS,
+ sizeof (elf_gregset_t), GENERAL_REGS,
+ riscv_fill_gregset, riscv_store_gregset },
+ { PTRACE_GETREGSET, PTRACE_SETREGSET, NT_FPREGSET,
+ sizeof (struct __riscv_mc_d_ext_state), FP_REGS,
+ riscv_fill_fpregset, riscv_store_fpregset },
+ { PTRACE_GETREGSET, PTRACE_SETREGSET, NT_FPREGSET,
+ sizeof (struct __riscv_mc_f_ext_state), FP_REGS,
+ riscv_fill_fpregset, riscv_store_fpregset },
+ NULL_REGSET
+};
+
+static struct regsets_info riscv_regsets_info =
+ {
+ riscv_regsets, /* regsets */
+ 0, /* num_regsets */
+ NULL, /* disabled_regsets */
+ };
+
+static struct regs_info riscv_regs =
+ {
+ NULL, /* regset_bitmap */
+ NULL, /* usrregs */
+ &riscv_regsets_info,
+ };
+
+/* Implementation of linux_target_ops method "regs_info". */
+
+static const struct regs_info *
+riscv_regs_info ()
+{
+ return &riscv_regs;
+}
+
+/* Implementation of linux_target_ops method "fetch_register". */
+
+static int
+riscv_fetch_register (struct regcache *regcache, int regno)
+{
+ const struct target_desc *tdesc = regcache->tdesc;
+
+ if (regno != find_regno (tdesc, "zero"))
+ return 0;
+ supply_register_zeroed (regcache, regno);
+ return 1;
+}
+
+/* Implementation of linux_target_ops method "get_pc". */
+
+static CORE_ADDR
+riscv_get_pc (struct regcache *regcache)
+{
+ elf_gregset_t regset;
+
+ if (sizeof (regset[0]) == 8)
+ return linux_get_pc_64bit (regcache);
+ else
+ return linux_get_pc_32bit (regcache);
+}
+
+/* Implementation of linux_target_ops method "set_pc". */
+
+static void
+riscv_set_pc (struct regcache *regcache, CORE_ADDR newpc)
+{
+ elf_gregset_t regset;
+
+ if (sizeof (regset[0]) == 8)
+ linux_set_pc_64bit (regcache, newpc);
+ else
+ linux_set_pc_32bit (regcache, newpc);
+}
+
+/* Correct in either endianness. */
+static const uint16_t riscv_ibreakpoint[] = { 0x0073, 0x0010 };
+static const uint16_t riscv_cbreakpoint = 0x9002;
+
+/* Implementation of linux_target_ops method "breakpoint_kind_from_pc". */
+
+static int
+riscv_breakpoint_kind_from_pc (CORE_ADDR *pcptr)
+{
+ union
+ {
+ gdb_byte bytes[2];
+ uint16_t insn;
+ }
+ buf;
+
+ if (target_read_memory (*pcptr, buf.bytes, sizeof (buf.insn)) == 0
+ && riscv_insn_length (buf.insn == sizeof (riscv_ibreakpoint)))
+ return sizeof (riscv_ibreakpoint);
+ else
+ return sizeof (riscv_cbreakpoint);
+}
+
+/* Implementation of linux_target_ops method "sw_breakpoint_from_kind". */
+
+static const gdb_byte *
+riscv_sw_breakpoint_from_kind (int kind, int *size)
+{
+ *size = kind;
+ switch (kind)
+ {
+ case sizeof (riscv_ibreakpoint):
+ return (const gdb_byte *) &riscv_ibreakpoint;
+ default:
+ return (const gdb_byte *) &riscv_cbreakpoint;
+ }
+}
+
+/* Implementation of linux_target_ops method "breakpoint_at". */
+
+static int
+riscv_breakpoint_at (CORE_ADDR pc)
+{
+ union
+ {
+ gdb_byte bytes[2];
+ uint16_t insn;
+ }
+ buf;
+
+ if (target_read_memory (pc, buf.bytes, sizeof (buf.insn)) == 0
+ && (buf.insn == riscv_cbreakpoint
+ || (buf.insn == riscv_ibreakpoint[0]
+ && target_read_memory (pc + sizeof (buf.insn), buf.bytes,
+ sizeof (buf.insn)) == 0
+ && buf.insn == riscv_ibreakpoint[1])))
+ return 1;
+ else
+ return 0;
+}
+
+struct linux_target_ops the_low_target =
+{
+ riscv_arch_setup,
+ riscv_regs_info,
+ NULL, /* cannot_fetch_register */
+ NULL, /* cannot_store_register */
+ riscv_fetch_register,
+ riscv_get_pc,
+ riscv_set_pc,
+ riscv_breakpoint_kind_from_pc,
+ riscv_sw_breakpoint_from_kind,
+ NULL, /* get_next_pcs */
+ 0, /* decr_pc_after_break */
+ riscv_breakpoint_at,
+};
+
+void
+initialize_low_arch ()
+{
+ initialize_regsets_info (&riscv_regsets_info);
+}
Index: binutils-gdb/gdb/nat/riscv-linux-tdesc.c
===================================================================
--- binutils-gdb.orig/gdb/nat/riscv-linux-tdesc.c
+++ binutils-gdb/gdb/nat/riscv-linux-tdesc.c
@@ -33,7 +33,7 @@
/* Determine XLEN and FLEN and return a corresponding target description. */
-const struct target_desc *
+struct target_desc *
riscv_linux_read_description (int tid)
{
struct riscv_gdbarch_features features;
Index: binutils-gdb/gdb/nat/riscv-linux-tdesc.h
===================================================================
--- binutils-gdb.orig/gdb/nat/riscv-linux-tdesc.h
+++ binutils-gdb/gdb/nat/riscv-linux-tdesc.h
@@ -22,6 +22,6 @@
struct target_desc;
/* Return a target description for the LWP identified by TID. */
-const struct target_desc *riscv_linux_read_description (int tid);
+struct target_desc *riscv_linux_read_description (int tid);
#endif /* NAT_RISCV_LINUX_TDESC_H */
From gdb-patches-return-163636-listarch-gdb-patches=sources.redhat.com@sourceware.org Wed Jan 29 18:39:53 2020
Return-Path: <gdb-patches-return-163636-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb-patches@sources.redhat.com
Received: (qmail 113575 invoked by alias); 29 Jan 2020 18:39:52 -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 113566 invoked by uid 89); 29 Jan 2020 18:39:52 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-16.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3 autolearn=ham version=3.3.1 spammyX-HELO: esa5.hgst.iphmx.com
Received: from esa5.hgst.iphmx.com (HELO esa5.hgst.iphmx.com) (216.71.153.144) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 Jan 2020 18:39:42 +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\x1580323183; x\x1611859183; hÚte:from:to:cc:subject:message-id:mime-version; bh=zaF+OY66OP/2firVHRE4Mn2cTg/Q9m9ne686326GVCY=; b=CQl4CN1wyV9Wfbt8Ln+OGU+2ehzPX+FPEUc2uCiW4LjfYwADz+wReqc6 KAx9EdAQ7pzRpo0Hi6uU1aDVyBgq3FmrlmPytYXPZcqljEsGqJotl3bCN AS45shGx4Wl3dK4ZW5v5+5l4ko2yomxmuSfOw5wxgOa/oGWQKlVcqcIIo Y/lrzUst4TQuvmqQq3G/D1aio+L43D3JkCAr+1KjmorkpIcA7YY+nLbQQ a5EuEM9S2tQ+a8iHEposUTv0hSJEgZOFGjN6v9qny1nWfBUHo626lKSls oQei4lA5X8yPwXTOC3emezP3szp037j7d22IUwJ3bBPXYzxJJXOqcJEJ6 Q==;
IronPort-SDR: hC8cZgharccMPy8Su+OIonnNkq1IfXw/oie0d/mBu63unJlpQb8SkiiXZPMrG/3CZI6vh6DBI1 VdCTFpcE+REPJg6SHIGM6YKojRKuU4FZMVmcp0duqk5jUCKaLP1vtBtsuadcnFj/CTrtnyTcFV Mo6Ly+eu5cphzHlc3BjDaneSGC61JzF2A8k8mWgsH2id6neG1FltI+0TvBGaFn9I8BbKcUOK1a D14+07d1q6nmJT+Krw9iqXQAiCd8puf/SR6yPxj8jhM6Ldg2gS3e41/gZVXmudw9Nr+7fLtL9I WYYReceived: from h199-255-45-14.hgst.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 30 Jan 2020 02:39:41 +0800
IronPort-SDR: lBhonbsq0MWILe1BQR2WDK4TJiz3R4+zb/w/xyNRXpn3qt5cxkszKKSN7Sm1DkOEMTNjCQvCUG MV7a5wIpQ0xslNyMAGtvzQ50cQhEvX6/wvbLQKMmSU+pt+NH5r1nK+cty3FowZbh5LNpo3pn4h SGMCCNv6IEEka69iglNpkXb8UUDfNkLZnn67lDeMslcoXkLdCTquaVzjq32C0EPbB7idRLINpO pAyReDitI0ccRNrsSZGa77XHwfb3tvLqF/2FfJbQCqy069mjrMx/1HTUtBB2ctBIVvgW0UL8hF C0nu0UAPH54jnKYNrt97yTq2
Received: from uls-op-cesaip02.wdc.com ([10.248.3.37]) by uls-op-cesaep01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jan 2020 10:32:53 -0800
IronPort-SDR: vkETWytWAFSfthzEV9O5N3J6QqN29i0FTKFl0cs9Biyjgalpl4//TrAT1V6okoLonOhQ6JsEye NLss4A3jhAkvMsFTXQitH+1NIV2j/snI/TA5Elji20NByUQiYJXhO+5buCdm53UetzAJC99Vpm zkveT2PK8aeR+xXYinTy/aLQa0ht0S2YY6zv7XWJS8n1V8q1Kaqhqj8zpWYMN3cdqsapAj79OX fU9p+oKjWvLsZjVnPi63hZ9iCHwue3lzBUM1etjEt2ho8h83AoiceU1nt+48cb3yu54f1X/NGG ae0WDCIronportException: Internal
Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 29 Jan 2020 10:39:39 -0800
Date: Wed, 29 Jan 2020 18:44:00 -0000
From: "Maciej W. Rozycki" <macro@wdc.com>
To: Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
cc: gdb-patches@sourceware.org, ulrich.weigand@de.ibm.com, rcardoso@linux.ibm.com
Subject: [OB PATCH] gdbserver: Fix whitespace configure.srv damage for `i[34567]86-*-mingw*'
Message-ID: <alpine.LFD.2.21.2001291829220.14118@redsun52.ssa.fujisawa.hgst.com>
User-Agent: Alpine 2.21 (LFD 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-SW-Source: 2020-01/txt/msg00950.txt.bz2
Content-length: 1709
Fix fallout from commit 42cd72aa0279 ("gdbserver: Make `make TAGS'
actually work") add a missing newline to configure.srv for
`i[34567]86-*-mingw*'.
gdb/gdbserver/
* configure.srv <i[34567]86-*-mingw*>: Fix whitespace damage.
---
On Wed, 29 Jan 2020, Pedro Franco de Carvalho wrote:
> I also noticed that the line in configure.srv for i[34567]86-*-mingw*)
> is missing a line break, but I don't have a mingw setup to test a fix
> and send it.
Well, this is obvious (and the terminal wrap hid the trailing tab making
it pretend to be a newline). Fixed thus, and committed.
Maciej
---
gdb/gdbserver/ChangeLog | 4 ++++
gdb/gdbserver/configure.srv | 3 ++-
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/gdb/gdbserver/ChangeLog b/gdb/gdbserver/ChangeLog
index 3b88a9b901e..9bc965a36b3 100644
--- a/gdb/gdbserver/ChangeLog
+++ b/gdb/gdbserver/ChangeLog
@@ -1,3 +1,7 @@
+2020-01-29 Maciej W. Rozycki <macro@wdc.com>
+
+ * configure.srv <i[34567]86-*-mingw*>: Fix whitespace damage.
+
2020-01-29 Pedro Franco de Carvalho <pedromfc@linux.ibm.com>
* configure.srv (powerpc*-*-linux*): Use srv_tgtobj in second
diff --git a/gdb/gdbserver/configure.srv b/gdb/gdbserver/configure.srv
index f0ab14f7c33..dba0733f1d7 100644
--- a/gdb/gdbserver/configure.srv
+++ b/gdb/gdbserver/configure.srv
@@ -124,7 +124,8 @@ case "${target}" in
srv_mingwce=yes
;;
i[34567]86-*-mingw*) srv_regobj=""
- srv_tgtobj="x86-low.o nat/x86-dregs.o win32-low.o" srv_tgtobj="${srv_tgtobj} win32-i386-low.o"
+ srv_tgtobj="x86-low.o nat/x86-dregs.o win32-low.o"
+ srv_tgtobj="${srv_tgtobj} win32-i386-low.o"
srv_tgtobj="${srv_tgtobj} arch/i386.o"
srv_mingw=yes
;;
--
2.11.0
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/3] RISC-V/Linux/native: Determine FLEN dynamically
2020-01-29 18:13 ` [PATCH v2 1/3] RISC-V/Linux/native: Determine FLEN dynamically Maciej W. Rozycki
@ 2020-01-29 23:26 ` Jim Wilson
2020-01-30 0:13 ` Maciej W. Rozycki
2020-01-30 23:19 ` Jim Wilson
1 sibling, 1 reply; 10+ messages in thread
From: Jim Wilson @ 2020-01-29 23:26 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: gdb-patches, Andrew Burgess, Palmer Dabbelt, Tom Tromey, guoren,
lifang_xia, yunhai_shang, jiangshuai_li
On Wed, Jan 29, 2020 at 10:13 AM Maciej W. Rozycki <macro@wdc.com> wrote:
> 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.
Looks OK to me, though I'm not an official reviewer.
I did notice a reference to FGR in a comment that should presumably be
FPR, but that is a very minor issue.
Jim
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 2/3] RISC-V/Linux/native: Factor out target description determination
2020-01-29 18:14 ` [PATCH v2 2/3] RISC-V/Linux/native: Factor out target description determination Maciej W. Rozycki
@ 2020-01-29 23:39 ` Jim Wilson
0 siblings, 0 replies; 10+ messages in thread
From: Jim Wilson @ 2020-01-29 23:39 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: gdb-patches, Andrew Burgess, Palmer Dabbelt, Tom Tromey, guoren,
lifang_xia, yunhai_shang, jiangshuai_li
On Wed, Jan 29, 2020 at 10:13 AM Maciej W. Rozycki <macro@wdc.com> wrote:
> gdb/
> * nat/riscv-linux-tdesc.h: New file.
> * nat/riscv-linux-tdesc.c: New file, taking code from...
> * riscv-linux-nat.c (riscv_linux_nat_target::read_description):
> ... here.
> * configure.nat <linux> <riscv*>: Add nat/riscv-linux-tdesc.o to
> NATDEPFILES.
Looks good to me, though I'm not an official reviewer.
Jim
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 3/3] gdbserver: Add RISC-V/Linux support
[not found] ` <alpine.LFD.2.21.2001291412560.14118@redsun52.ssa.fujisawa.hgst.com>
@ 2020-01-30 0:00 ` Jim Wilson
2020-01-30 1:58 ` Maciej W. Rozycki
0 siblings, 1 reply; 10+ messages in thread
From: Jim Wilson @ 2020-01-30 0:00 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: gdb-patches, Andrew Burgess, Palmer Dabbelt, Tom Tromey, guoren,
lifang_xia, yunhai_shang, jiangshuai_li
On Wed, Jan 29, 2020 at 10:14 AM Maciej W. Rozycki <macro@wdc.com> wrote:
> gdb/
> * arch/riscv.h (riscv_create_target_description): Remove `const'
> qualifier from the return type.
> * arch/riscv.c (riscv_create_target_description): Likewise.
> * nat/riscv-linux-tdesc.h (riscv_linux_read_description):
> Likewise.
> * nat/riscv-linux-tdesc.c (riscv_linux_read_description):
> Likewise.
> * configure.tgt <riscv*-*-linux*>: Set build_gdbserver=yes.
>
> gdb/gdbserver/
> * linux-riscv-low.c: New file.
> * Makefile.in (SFILES): Add linux-riscv-low.c, arch/riscv.c, and
> nat/riscv-linux-tdesc.c.
> * configure.srv <riscv*-*-linux*> (srv_tgtobj)
> (srv_linux_regsets, srv_linux_usrregs, srv_linux_thread_db):
> Define.
Looks good to me, though I'm not an official review.
I noticed on the gdbserver console I'm getting a lot of ptrace warnings.
ptrace(regsets_fetch_inferior_registers) PID=1678103: Invalid argument
Warning: ptrace(regsets_store_inferior_registers): Invalid argument
This looks like a side effect of having two FP regsets defined, it
tries the first one, fails, and then tries the second one which is
correct. If you mark them as OPTIONAL_REGS we would only get the
warning once which would be OK, except that they can't be both FP_REGS
and OPTIONAL_REGS at the same time. I don't know what if anything
would break if they aren't marked as FP_REGS. I only see explicit
checks for GENERAL_REGS and OPTIONAL_REGS; I don't see any checks for
FP_REGS. Anyways, I would suggest as a future improvement that the
linux gdbserver regset support be extended so that a regset can be
marked as both FP_REGS and OPTIONAL_REGS.
There are some new functions and structures that don't have
explanatory comments before them, but this is a minor issue.
Jim
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/3] RISC-V/Linux/native: Determine FLEN dynamically
2020-01-29 23:26 ` Jim Wilson
@ 2020-01-30 0:13 ` Maciej W. Rozycki
0 siblings, 0 replies; 10+ messages in thread
From: Maciej W. Rozycki @ 2020-01-30 0:13 UTC (permalink / raw)
To: Jim Wilson
Cc: gdb-patches, Andrew Burgess, Palmer Dabbelt, Tom Tromey, guoren,
lifang_xia, yunhai_shang, jiangshuai_li
On Wed, 29 Jan 2020, Jim Wilson wrote:
> I did notice a reference to FGR in a comment that should presumably be
> FPR, but that is a very minor issue.
FGR as in Floating-point General-purpose Register (as opposed to a
floating-point control register). Maybe it's too uncommon a use and need
a full expansion here.
Maciej
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 3/3] gdbserver: Add RISC-V/Linux support
2020-01-30 0:00 ` [PATCH v2 3/3] gdbserver: Add RISC-V/Linux support Jim Wilson
@ 2020-01-30 1:58 ` Maciej W. Rozycki
0 siblings, 0 replies; 10+ messages in thread
From: Maciej W. Rozycki @ 2020-01-30 1:58 UTC (permalink / raw)
To: Jim Wilson
Cc: gdb-patches, Andrew Burgess, Palmer Dabbelt, Tom Tromey, guoren,
lifang_xia, yunhai_shang, jiangshuai_li
On Wed, 29 Jan 2020, Jim Wilson wrote:
> I noticed on the gdbserver console I'm getting a lot of ptrace warnings.
> ptrace(regsets_fetch_inferior_registers) PID=1678103: Invalid argument
> Warning: ptrace(regsets_store_inferior_registers): Invalid argument
> This looks like a side effect of having two FP regsets defined, it
> tries the first one, fails, and then tries the second one which is
> correct. If you mark them as OPTIONAL_REGS we would only get the
> warning once which would be OK, except that they can't be both FP_REGS
> and OPTIONAL_REGS at the same time. I don't know what if anything
> would break if they aren't marked as FP_REGS. I only see explicit
> checks for GENERAL_REGS and OPTIONAL_REGS; I don't see any checks for
> FP_REGS. Anyways, I would suggest as a future improvement that the
> linux gdbserver regset support be extended so that a regset can be
> marked as both FP_REGS and OPTIONAL_REGS.
Hmm, good point. I think OPTIONAL_REGS might become a flag, however as
you have observed there seems to be no special meaning indeed to FP_REGS
and actually only a couple of `gdbserver' hosts use this type, so using
OPTIONAL_REGS should be fine. I'll send an update.
> There are some new functions and structures that don't have
> explanatory comments before them, but this is a minor issue.
Right, though I think they are self-explanatory.
Maciej
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/3] RISC-V/Linux/native: Determine FLEN dynamically
2020-01-29 18:13 ` [PATCH v2 1/3] RISC-V/Linux/native: Determine FLEN dynamically Maciej W. Rozycki
2020-01-29 23:26 ` Jim Wilson
@ 2020-01-30 23:19 ` Jim Wilson
2020-01-31 0:06 ` Andreas Schwab
2020-01-31 12:11 ` Maciej W. Rozycki
1 sibling, 2 replies; 10+ messages in thread
From: Jim Wilson @ 2020-01-30 23:19 UTC (permalink / raw)
To: Maciej W. Rozycki
Cc: gdb-patches, Andrew Burgess, Palmer Dabbelt, Tom Tromey, guoren,
lifang_xia, yunhai_shang, jiangshuai_li
On Wed, Jan 29, 2020 at 10:13 AM Maciej W. Rozycki <macro@wdc.com> wrote:
> 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.
I forgot to mention this before, but our long term plans are to pass
info via the auxiliary vector from the kernel to the application, and
then in theory gdb should be able to get architecture info from there.
This may require support that hasn't been written yet, and we may
still need the fp probing for older systems that don't have all of the
support needed to make aux vec work. Just with a quick check on my
4.15 kernel, I see
hifiveu017:1030$ ./a.out
AT_HWCAP = 0x1105
that is 'a', 'c', 'i', and 'm', each represented as 1<<(x-'a'). The
'f' and 'd' info is missing for some reason. Maybe it hadn't been
implemented yet in this kernel version.
Jim
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/3] RISC-V/Linux/native: Determine FLEN dynamically
2020-01-30 23:19 ` Jim Wilson
@ 2020-01-31 0:06 ` Andreas Schwab
2020-01-31 12:11 ` Maciej W. Rozycki
1 sibling, 0 replies; 10+ messages in thread
From: Andreas Schwab @ 2020-01-31 0:06 UTC (permalink / raw)
To: Jim Wilson
Cc: Maciej W. Rozycki, gdb-patches, Andrew Burgess, Palmer Dabbelt,
Tom Tromey, guoren, lifang_xia, yunhai_shang, jiangshuai_li
On Jan 30 2020, Jim Wilson wrote:
> Just with a quick check on my
> 4.15 kernel, I see
> hifiveu017:1030$ ./a.out
> AT_HWCAP = 0x1105
> that is 'a', 'c', 'i', and 'm', each represented as 1<<(x-'a'). The
> 'f' and 'd' info is missing for some reason. Maybe it hadn't been
> implemented yet in this kernel version.
Your kernel is just too archaic to include commit 732e8e4130ff.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [PATCH v2 1/3] RISC-V/Linux/native: Determine FLEN dynamically
2020-01-30 23:19 ` Jim Wilson
2020-01-31 0:06 ` Andreas Schwab
@ 2020-01-31 12:11 ` Maciej W. Rozycki
1 sibling, 0 replies; 10+ messages in thread
From: Maciej W. Rozycki @ 2020-01-31 12:11 UTC (permalink / raw)
To: Jim Wilson
Cc: gdb-patches, Andrew Burgess, Palmer Dabbelt, Tom Tromey, guoren,
lifang_xia, yunhai_shang, jiangshuai_li
On Thu, 30 Jan 2020, Jim Wilson wrote:
> > 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.
>
> I forgot to mention this before, but our long term plans are to pass
> info via the auxiliary vector from the kernel to the application, and
> then in theory gdb should be able to get architecture info from there.
Thanks for the heads-up. This will undoubtedly be useful for something,
but I think we have a solution for GDB/gdbserver already, so unless the
circumstances change, I think we're fine without the need to peek at the
auxv.
I'll be posting v3, which has just passed testing, right away. It
includes a few further improvements beyond what has been already
discussed.
Maciej
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2020-01-31 10:43 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <alpine.LFD.2.21.2001291207310.14118@redsun52.ssa.fujisawa.hgst.com>
2020-01-29 18:13 ` [PATCH v2 1/3] RISC-V/Linux/native: Determine FLEN dynamically Maciej W. Rozycki
2020-01-29 23:26 ` Jim Wilson
2020-01-30 0:13 ` Maciej W. Rozycki
2020-01-30 23:19 ` Jim Wilson
2020-01-31 0:06 ` Andreas Schwab
2020-01-31 12:11 ` Maciej W. Rozycki
2020-01-29 18:14 ` [PATCH v2 2/3] RISC-V/Linux/native: Factor out target description determination Maciej W. Rozycki
2020-01-29 23:39 ` Jim Wilson
[not found] ` <alpine.LFD.2.21.2001291412560.14118@redsun52.ssa.fujisawa.hgst.com>
2020-01-30 0:00 ` [PATCH v2 3/3] gdbserver: Add RISC-V/Linux support Jim Wilson
2020-01-30 1:58 ` Maciej W. Rozycki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox