From patchwork Wed Nov 6 20:52:18 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Maciej W. Rozycki" X-Patchwork-Id: 35704 Received: (qmail 2176 invoked by alias); 6 Nov 2019 20:52:25 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 2167 invoked by uid 89); 6 Nov 2019 20:52:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.8 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_LOTSOFHASH autolearn=ham version=3.3.1 spammy=non-stop, complement, HX-Languages-Length:4562 X-HELO: esa2.hgst.iphmx.com Received: from esa2.hgst.iphmx.com (HELO esa2.hgst.iphmx.com) (68.232.143.124) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 06 Nov 2019 20:52:23 +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=1573073545; x=1604609545; h=date:from:to:cc:subject:in-reply-to:message-id: references:mime-version; bh=xpcZdJtrtrQ6cF3V7par2Supn6YVUNfg6S0G1aq14r8=; b=SVuEzJ25gOwZA3jUW9Nr2H8uIX9rMQe4zViggGvnhBA6Ru/uIH+ncxwb OWfisyUIs82U85Ytz+59isbJcqIqORsvPcnsFRA+5L214p23KkNp5U7K4 SiMwzcCqrlVcwqN/Xi35RZxPmdli5GS/5Bu5imEC5W7w5oRhnWoLAgvXn fOZikFkTSe9tPq7+rH4lo7xbEz2ZXltygMl5cTqa/AZaPBZCsUhNP6DwB /jGAfAbd66Q1JLJwBgOR0jEzCxcAAwG0Lkgv42eo9KKzC3egoiZ//Z3vW ONmx38mAfNqimvP3oIyH/P0biHPllTeKp+s0wTT47k9ztOMqLLNYuS2lA Q==; IronPort-SDR: yf1nqL+W2jEEn3KRw26URNlUSGJYGLwYJZthVW7qPZnrlWSAlHFYFyZxUnywgc/Byo6JXHnYYM s3fmqa5DT9tUpoqV2LYtFxxN3X0X+DUZG5tc8KfV3B5KBhGJjuyXeG42ilLkgnTf/9dfL/+c6K joUVjsipNTA479qB6zkxWdA1cxlFsnMpzJiiFUMxzJIxqbCBEvy1r1I3gqiWhTbuDfC5vNtwXB PEUDYLpwzkZ7h0BXh0eTgFKZL+012eM7cdpnjvJ4i9ZIuZrF22BiRXL6B2WU+Al0V9Lw6Oamoc LXY= Received: from h199-255-45-15.hgst.com (HELO uls-op-cesaep02.wdc.com) ([199.255.45.15]) by ob1.hgst.iphmx.com with ESMTP; 07 Nov 2019 04:52:23 +0800 IronPort-SDR: eq480l5MocFXKYzLJZpbSAIzcCurQEpvn3p7YGfMNfww703KAD//UimTlvOxfn0feaH5TssTIY TAq3tPxVdD5fk9NIgtZn3UlNFceoZpJQNvhOCjtnBlrCP4Ke0def9pNz3g3tTjwOYBYVm6wZFk oR7QiVtdtMRIfPC3q9bRsdsUNCbjcwDgZSXo3vkGHPuROt/hoEOMkam2h2Z6rQ+IEk+T08aFX6 bmrR8au1u+b349MWd1aTWEIKMukEJIjQ8hh8czn9n2A8Stney7tYlVa6a4A3Kts1T/W35TmTUJ 52V6bxRdZxKHee18yBNNZfCD Received: from uls-op-cesaip01.wdc.com ([10.248.3.36]) by uls-op-cesaep02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2019 12:47:33 -0800 IronPort-SDR: UEkDBghguDdmE0w351eyNKmPWq3Ms6Vd3pMaXM1dWHuY3u1MuYQjyVeUi6TZ01hfgDsU0NvnbG +P3rdwJ7smmlL4JKEPNg407jzS+GqAICcQpNo1w1Ue02y8PN33QRrsusp+efXH4oV99jZuW2sm u0+3IXTzPtjM5jTq3/qmrhuY6F/91uE4Wjxywk494tpVXPlAE0fSm/CyWzI6GQdorF9Qn1Ry8p FzGl/xuFJH8BmO3Ts8A7QaWUZ241nRpXV97IcTdKB1Ht9I6QZbyyhhCPxlA35MwgFMkkto1iTC 4ig= WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip01.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 06 Nov 2019 12:52:21 -0800 Date: Wed, 6 Nov 2019 20:52:18 +0000 (GMT) From: "Maciej W. Rozycki" To: Pedro Alves , gdb-patches@sourceware.org cc: Jim Wilson Subject: [PATCH v2 3/4] Remove breakpoint step-over information if failed to resume In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LFD 202 2017-01-01) MIME-Version: 1.0 Complement commit 31e77af205cf ("PR breakpoints/7143 - Watchpoint does not trigger when first set") and commit 71d378ae60a4 ("gdb.base/breakpoint-in-ro-region.exp regression on sss targets (PR gdb/22583)") and also remove breakpoint step-over information if the inferior has failed to resume, which may be due to for example a failure to insert a software breakpoint at an inaccessible location. If this happens, the state of GDB becomes inconsistent and further attempts to start execution hang. This was observed with a `riscv64-linux-gnu' cross-GDB and RISC-V/Linux `gdbserver' being developed and an attempt to step over the `ret' aka `c.jr ra' instruction where the value held in the `ra' aka `x1' register and therefore the address of a software-stepping breakpoint to insert is 0. Here's a record of a remote debug session leading to the issue: Sending packet: $vCont?#49...Packet received: vCont;c;C;t Packet vCont (verbose-resume) is supported Sending packet: $vCont;c:p23cb.-1#08...Packet received: T05swbreak:;02:20da080000000000;20:b807565515000000;thread:p23cb.23cb;core:3; Sending packet: $qXfer:libraries-svr4:read::0,1000#20...Packet received: l Sending packet: $X15555607b8,2:\202\200#2e...Packet received: OK Sending packet: $m15555607b8,2#07...Packet received: 8280 Sending packet: $m15555607b8,2#07...Packet received: 8280 Sending packet: $g#67...Packet received: 0000000000000000000000000000000020da08000000000000000000000000000000000000000000d0ae040000000000696e74000000000000000000000000000100000000000000020000000000000080d708000000000000000000000000000c0000000000000000000000000000000000000000000000000000000000000000e408000000000020e908000000000000000000000000000000000000000000d0ae04000000000072697363765f646f00000000000000000100000000000000030000000000000000e408000000000020f208000000000000000000000000000000000000000000d0ae04000000000072697363765f646f0000000000000000[552 bytes omitted] Sending packet: $m0,40#2d...Packet received: E01 Sending packet: $m0,1#fa...Packet received: E01 Sending packet: $m0,40#2d...Packet received: E01 Sending packet: $m0,1#fa...Packet received: E01 Cannot access memory at address 0x0 (gdb) stepi Sending packet: $m15555607b8,4#09...Packet received: 82802a87 Sending packet: $m15555607b4,4#05...Packet received: 01452dbd ^Cremote_pass_ctrlc called remote_interrupt called ^Cremote_pass_ctrlc called Interrupted while waiting for the program. Give up waiting? (y or n) y Quit (gdb) As observed here the `stepi' command does not even attempt to reinsert the breakpoint, let alone resume execution. Correct the issue by making a call to clear global breakpoint step-over from the exception catch clause in `resume'. With the change applied further `stepi' commands correctly retry breakpoint insertion: (gdb) stepi Sending packet: $m15555607b8,4#09...Packet received: 82802a87 Sending packet: $m15555607b4,4#05...Packet received: 01452dbd Sending packet: $m15555607b8,2#07...Packet received: 8280 Sending packet: $m15555607b8,2#07...Packet received: 8280 Sending packet: $m0,40#2d...Packet received: E01 Sending packet: $m0,1#fa...Packet received: E01 Sending packet: $m0,40#2d...Packet received: E01 Sending packet: $m0,1#fa...Packet received: E01 Cannot access memory at address 0x0 (gdb) and changing the value of the `pc' register so as not to point at a `ret' instruction allows execution to be actually resumed. gdb/ * infrun.c (resume): Also call `clear_step_over_info' in the `catch' clause. --- Changes from v1: - Add a thread number argument to `clear_step_over_info'. --- gdb/infrun.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) gdb-resume-clear-step-over-info.diff Index: binutils-gdb/gdb/infrun.c =================================================================== --- binutils-gdb.orig/gdb/infrun.c +++ binutils-gdb/gdb/infrun.c @@ -2620,7 +2620,12 @@ resume (gdb_signal sig) single-step breakpoints perturbing other threads, in case we're running in non-stop mode. */ if (inferior_ptid != null_ptid) - delete_single_step_breakpoints (inferior_thread ()); + { + thread_info *tp = inferior_thread (); + + delete_single_step_breakpoints (tp); + clear_step_over_info (tp->global_num); + } throw; } }