From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105719 invoked by alias); 21 Jan 2020 05:47:47 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 105705 invoked by uid 89); 21 Jan 2020 05:47:47 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.3 required=5.0 tests=AWL,BAYES_00,KAM_LOTSOFHASH,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 spammy= X-HELO: simark.ca Received: from simark.ca (HELO simark.ca) (158.69.221.121) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 21 Jan 2020 05:47:37 +0000 Received: from [10.0.0.11] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 444E91E5F7; Tue, 21 Jan 2020 00:47:35 -0500 (EST) Subject: Re: [PATCH v2 3/4] Remove breakpoint step-over information if failed to resume To: "Maciej W. Rozycki" , Pedro Alves , gdb-patches@sourceware.org Cc: Jim Wilson References: From: Simon Marchi Message-ID: <725c01dc-5f15-ea7d-4ce8-6b39befcb347@simark.ca> Date: Tue, 21 Jan 2020 08:29:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2020-01/txt/msg00625.txt.bz2 On 2019-11-06 3:52 p.m., Maciej W. Rozycki wrote: > 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. That looks ok to me, but again, I'd prefer if Pedro could take a look. Simon