From patchwork Wed Oct 30 14:26:06 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: 35471 Received: (qmail 44437 invoked by alias); 30 Oct 2019 14:26:16 -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 44349 invoked by uid 89); 30 Oct 2019 14:26:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3, KAM_LOTSOFHASH autolearn=ham version=3.3.1 spammy=talked, sk:breakpo, UD:orig, sk:riscv64 X-HELO: esa6.hgst.iphmx.com Received: from esa6.hgst.iphmx.com (HELO esa6.hgst.iphmx.com) (216.71.154.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Oct 2019 14:26:13 +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=1572445573; x=1603981573; h=date:from:to:cc:subject:message-id:mime-version; bh=UHRiuQbXWEAb/8lUmAGjYGDEk/WrWgqr0CB3es2T1M4=; b=IDR6UsTw8N/htcRLVVIMocaqntO8HY5dEIvSU397G+PL57So3AckXpfC mx+tFQBuADArDImv/krnl5akPMHpHc7f9dwxYZ+3ezbh+2AWMq9PrD/Kz EQ7+Gr90/TaA5VjiCxvBBf0+ykA10bEnreq6/wpQ8buX1H4eVlJ3DrWG/ AMTi8RjsHVezv7jde1Iik8OWBiOi9BEIqjJlT8GinMwpKI88ZR6dFyr9w fvt82VjGGfefJB9JlCZ0VERBIPlQe+bJH3X2R3VJYKASVEK3YHicmO5bu v0gg44fSmlqnM5Fc9L19OIr2OCXPKB113ez9/AIbtljhi7+kUdWjL49su w==; IronPort-SDR: keEmzKatXpivPF0zEyL3knKCXgLND+CuEZu1KYCxtwqgnjkDoxxi7ZEli5AiqTIfuwV5kR5s3j GlzmLX8++y8ReRxUBzo7zJQ304K925FYabeqZu653MomnGi8eO76s7qxwCQbqiSGw6KUUi/xpg kIiiDvDXobpWivBUPEPa+cvff7qf5eqS5/qfS7DqAPhEXQyZjJHMIyqNAv9uLDp/s1A+kxVr1I Zbo6ofMBiTF1TwFIgBl3FpG158HanbB6d5JRgJxAnjFc0B0Oai9GHwEQw1RZAPELIf5c34erAT AAE= Received: from uls-op-cesaip01.wdc.com (HELO uls-op-cesaep01.wdc.com) ([199.255.45.14]) by ob1.hgst.iphmx.com with ESMTP; 30 Oct 2019 22:26:12 +0800 IronPort-SDR: wxRB0SUaxW6VeTRS9Brth0mJaicm1VQaVND6SyiexMLMaDDu+sOxCQbqq5euLxV36B/SY78yDu +gw42zHKJeOq20ZucwvCriPDuVPvdL+QJHJptI1D15OST6jWBEZGdYISpyHzpFVkWcJDeao03B i7d6zd/Eek4c4pNGJ6H3d6zyfzBEyuIwR7Uocy5aDdKf4cjiUxaV3C0Pz3/nnGTTtKnR7tixbI ZtC4EXbduTeSVmpC8mAV1FsEDrbf1j28GCeW2cxV3ZDKOCLeSIYE7c6/7VwziBjH0AH/3U23Vp u1saABi40hgxGh36qHi3ROqo 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; 30 Oct 2019 07:21:30 -0700 IronPort-SDR: +MoXyeI1zUbPqd3Vw3co1ceWCoBG+AKeVZURwkcrqoBQ26ERDygOuKLjxY80vFw1xviJXKlMHC M3I0LBqDX5NjVqtE4+Hnw3Nw6hLDqLhbLrusuWUsWz29WCfcg/cK7o7KMPOYmV7evuvR4vWlY8 e0Iy/t6PPCGE7kJITk9J2CV9AIZe2tRDpmle2618M6S0njS8SNBDvVvT1aec+jg63HywiTqD/f Uo0KIZciQ2A2qVMYRtGlbVPe2EF6wzci2uRHl/kJ9VfbG1Ud168e913JKdQma2FFkSkXmfhBQn u/w= WDCIronportException: Internal Received: from unknown (HELO redsun52) ([10.149.66.28]) by uls-op-cesaip02.wdc.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 30 Oct 2019 07:26:12 -0700 Date: Wed, 30 Oct 2019 14:26:06 +0000 (GMT) From: "Maciej W. Rozycki" To: gdb-patches@sourceware.org cc: Pedro Alves , Jim Wilson Subject: [PATCH] Remove breakpoint step-over information if failed to resume Message-ID: 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. --- Hi, NB, this complements rather than replacing the ("Remove stale breakpoint step-over information") proposed change recorded here: ; we still need to clean the breakpoint step-over information if single-stepping did proceed as requested, but then hung and was forcibly interrupted (as it could happen if say an RSP JTAG probe being talked to stopped responding). For completeness this change was natively regression-tested with the `x86_64-linux-gnu' configuration, although I'd consider it obviously harmless and only relevant to the affected scenarios. I think it would be good to have such a scenario covered in our test suite, however this is highly target-specific. I'll try to think about a test case, however it may not be right away that I come up with one. Meanwhile, OK to apply? Maciej --- gdb/infrun.c | 5 ++++- 1 file changed, 4 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 @@ -2617,7 +2617,10 @@ 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 ()); + { + delete_single_step_breakpoints (inferior_thread ()); + clear_step_over_info (); + } throw; } }