[PATCH v3 0/3] RISC-V/Linux `gdbserver' support and associated fixes

[PATCH v3 0/3] RISC-V/Linux `gdbserver' support and associated fixes

[Maciej W. Rozycki]

Hi,

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

 Beyond the issues discussed with v2 I have now also slightly optimised 
regcache supply/collect handlers to avoid doing a costly variable 
multiplication in a loop, and added buffer offset precalculations so as to 
avoid excessive line wrapping and hopefully making code more readable.

 Also I have noticed missing Python and ncurses development libraries 
limiting testing in my native setup.  With these installed native test 
results improved a little, as follows:

		=== gdb Summary ===

# of expected passes		61354
# of unexpected failures	1636
# of unexpected successes	1
# of expected failures		58
# of unknown successes		3
# of known failures		85
# of unresolved testcases	113
# of untested testcases		160
# of unsupported tests		323

however a worrying regression has appeared:

FAIL: gdb.base/return-nodebug.exp: float: full width of the returned result

This has turned out not to be related to this patch series however and 
triggers reliably now in my setup regardless of whether this patch set has 
been applied or not.  Instead it is an outcome of GDB failing to NaN-box 
data of the `float' type when assigning it to a hardware register.

 I have filed PR tdep/25489 to track it as I may not be able to look into 
it right away.

 Except as noted above here 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).

 As usually see individual changes for details.

  Maciej

Re: [PATCH v3 0/3] RISC-V/Linux `gdbserver' support and associated fixes

[Maciej W. Rozycki]

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

On Fri, 31 Jan 2020, Maciej W. Rozycki wrote:

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

 Apologies for the series being broken, there appears to be something here 
in the e-mail setup that causes `In-Reply-To:' and `References:' headers 
to be randomly dropped sometimes and I haven't figured out what the exact 
circumstances are.

 In any case the changes themselves are:

<https://sourceware.org/ml/gdb-patches/2020-01/msg00994.html>
<https://sourceware.org/ml/gdb-patches/2020-01/msg00995.html>
<https://sourceware.org/ml/gdb-patches/2020-01/msg00996.html>

  Maciej
From gdb-patches-return-163686-listarch-gdb-patches=sources.redhat.com@sourceware.org Fri Jan 31 13:00:45 2020
Return-Path: <gdb-patches-return-163686-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb-patches@sources.redhat.com
Received: (qmail 89590 invoked by alias); 31 Jan 2020 13:00:43 -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 89076 invoked by uid 89); 31 Jan 2020 13:00:28 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.1 spammy=submissions, HX-Languages-Length:932, submission, you!
X-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; Fri, 31 Jan 2020 13:00:24 +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\x1580475623; x\x1612011623;  hÚte:from:to:cc:subject:in-reply-to:message-id:   references:mime-version;  bh=Om54pjzFHWfnQt86uZTGwyUnjg3EXOCfw3cKQzS4juU=;  b=dUxirqlYpu4vuEo1dAc6Gcm3Xmn7792YBu0MOB09BfAFyCNhevsTJ/8l   rLkMNgStgjfBN13d1RzLa2ilGxuUzUykAb2YfpZkAJ6gBA5PnRnX+Rxzd   IQWuA8FUsaPZsX/jtcNVnjJS+TOwyDdyOjRNWPPm/I9z3zKUwRtYg4XaX   4fn2JFfcN8RPn4VHJNprGwXnTXMH4ryIytgK0lzmgLESjMUNzgTK+/Ohs   T76lcJcOep3LsVYD/canoQ/Ue6CyqPrgihsywfkXGCLfOftk/QDJusYbi   BqL5zENTV43VWIvUcb7T+PGCJZlYE5McKmvGL1uaZbar3LZmFiXxvd0CY   w==;
IronPort-SDR: SbKUwVCVqBTpDwr2DpdtofYra20WHkVRXEQIQ9+0fbf/57Ej+7p9mrAH+T+HQ6fighbinyWzbK +YxYDaFhgn43P0AmV0r2YXwSyui7uzjFc4uvSyp5m1Ixey+0moOLkkvcHZWTxmDHl1LyaG8j3+ zB88XCWpwTAbAOQF7pL2XGwBiXYZblfy+euBFB5tK/sOjZ7c02glRmreW8MMBsesHovXqhCYB5 3AO7XmOrWp5EnYEgY4H12U1tl8fCHFSzw79NtRBr3GvGE2hqNag+mF7pgk+G6sMhRUMSFfmToM LOUReceived: from h199-255-45-14.hgst.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14])  by ob1.hgst.iphmx.com with ESMTP; 31 Jan 2020 21:00:22 +0800
IronPort-SDR: YDL0LGGyOZKj2R8V93IpzWbOyczfH+/Kpb8GImF23UOlk+1kX3501ukk7V8eMM2+73txd8Q+2d G28GqNH0rPfaqh0iCNJGTNt0O+p5K7F+byFMxzW4D2bXDPcRWnnmtgo2MRo89qBnUErw/4zx4c 5hae6d1AS5McE1nOAhjnnRrrzDI2b5K8VuKU2BeFy3UbokskJldtlXfFnseyz65g4cvTFvAepo dilrkFYtSMq+UemlYAqPx/bV6lWs8Z7Txx9KvbsheU5R+gN7EPaOB2pFpQt7/bot3T5PxJbh/d toYyI16yKWFy6OquLkgXPN1g
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; 31 Jan 2020 04:53:31 -0800
IronPort-SDR: P84cl/V2DbTA+a4YK138jaH6UP88VylMoYS9OIlLsIQBOR28o77W0jEMb11EGpcduAfNoLCHOb zygA7e86QrK6HN/58mTSolr3CRwEJGU2lj4uTT0IwI1k0JZlTX+1lsaoJWszJChIkoE283zmbX mNrKuofA9o5I/paQnlbQJkymyGtAv57tNLjOMxmbDX96SC3z9NWsf6aWvUpypNSuMtWaHV+5ZM GGM9BW9stIpdWpWbKqkkyvm+lF9olQ0rGHoeodx4owTXZ7es6R4Sl7S2OfZsVrTPjlUnTCjcQ7 D5cWDCIronportException: Internal
Received: from unknown (HELO redsun52) ([10.149.66.28])  by uls-op-cesaip02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 31 Jan 2020 05:00:22 -0800
Date: Fri, 31 Jan 2020 14:23:00 -0000
From: "Maciej W. Rozycki" <macro@wdc.com>
To: gdb-patches@sourceware.org
cc: Simon Marchi <simark@simark.ca>, Pedro Alves <palves@redhat.com>
Subject: [PING^9][PATCH v2 0/4] GDB fixes for the remote end having gone astray
In-Reply-To: <alpine.LFD.2.21.1911051509370.13542@redsun52.ssa.fujisawa.hgst.com>
Message-ID: <alpine.LFD.2.21.2001311252490.14118@redsun52.ssa.fujisawa.hgst.com>
References: <alpine.LFD.2.21.1911051509370.13542@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/msg01000.txt.bz2
Content-length: 871

On Wed, 6 Nov 2019, Maciej W. Rozycki wrote:

>  As issues from software stepping having gone astray seem to have started
> piling up, and with your suggested modifications there is now a dependency
> between the changes, I have decided to make this patch submission a small
> series with 1/4 and 3/4 corresponding to original individual submissions
> and 2/4 and 4/4 being entrely new fixes.

 Where are we with this series:

<https://sourceware.org/ml/gdb-patches/2019-11/msg00191.html>
<https://sourceware.org/ml/gdb-patches/2019-11/msg00192.html>
<https://sourceware.org/ml/gdb-patches/2019-11/msg00193.html>
<https://sourceware.org/ml/gdb-patches/2019-11/msg00194.html>

?  Simon was kind enough (thank you!) to partially review 1-3/4, but I
need a final word on these, and also input on 4/4.  I will appreciate
assistance with moving this forward.

  Maciej