From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 91831 invoked by alias); 21 Jan 2020 05:34:27 -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 91817 invoked by uid 89); 21 Jan 2020 05:34:26 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.4 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=held, alive, forcibly, hes 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:34:18 +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) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id BA97D1E5F7; Tue, 21 Jan 2020 00:34:16 -0500 (EST) Subject: Re: [PATCH v2 1/4] Remove stale breakpoint step-over information To: "Maciej W. Rozycki" , Pedro Alves , gdb-patches@sourceware.org Cc: Jim Wilson References: From: Simon Marchi Message-ID: <05f8f157-1d6a-57e1-4bee-a9e17e5ed54d@simark.ca> Date: Tue, 21 Jan 2020 05:41: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/msg00623.txt.bz2 On 2019-11-06 3:51 p.m., Maciej W. Rozycki wrote: > Fix an issue with the `step_over_info' structure introduced with commit > 31e77af205cf ("PR breakpoints/7143 - Watchpoint does not trigger when > first set"), where information stored in there is not invalidated in a > remote debug scenario where software stepping in the all-stop mode is > forcibly interrupted and the target connection then closed. As a result > a subsequent target connection triggers an assertion failure on > `ecs->event_thread->control.trap_expected' and cannot be successfully > established, making the particular instance of GDB unusable. > > 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, as follows: > > (gdb) target remote 1.2.3.4:56789 > Remote debugging using 1.2.3.4:56789 > warning: while parsing target description (at line 4): Target description specified unknown architecture "riscv:rv64id" > warning: Could not load XML target description; ignoring > Reading symbols from .../sysroot/lib/ld-linux-riscv64-lp64d.so.1... > 0x0000001555556ef0 in _start () > from .../sysroot/lib/ld-linux-riscv64-lp64d.so.1 > (gdb) break main > Breakpoint 1 at 0x1643c > (gdb) continue > Continuing. > Cannot access memory at address 0x0 > (gdb) x /i $pc > => 0x15555607b8 <__GI__dl_debug_state>: ret > (gdb) print /x $ra > $1 = 0x0 > (gdb) stepi > ^C^CInterrupted while waiting for the program. > Give up waiting? (y or n) y > Quit > (gdb) kill > Kill the program being debugged? (y or n) y > [Inferior 1 (process 8964) killed] > (gdb) target remote 1.2.3.4:56789 > Remote debugging using 1.2.3.4:56789 > warning: while parsing target description (at line 4): Target description specified unknown architecture "riscv:rv64id" > warning: Could not load XML target description; ignoring > .../gdb/infrun.c:5299: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Quit this debugging session? (y or n) y > > This is a bug, please report it. For instructions, see: > . > > .../gdb/infrun.c:5299: internal-error: int finish_step_over(execution_control_state*): Assertion `ecs->event_thread->control.trap_expected' failed. > A problem internal to GDB has been detected, > further debugging may prove unreliable. > Create a core file of GDB? (y or n) n > Command aborted. > (gdb) > > Correct the issue by making a call to clear global breakpoint step-over > information from `clear_thread_inferior_resources'. To do so add an > argument to `clear_step_over_info' giving the global thread number to > check against, complementing one given to `set_step_over_info' when the > information concerned is recorded, so that information is not removed > for a thread that has stayed alive in a multi-target scenario. > > Adjust all the existing `clear_step_over_info' call sites accordingly > where a step over has completed successfully and the thread that has > hit the breakpoint is expected to be one for which the breakpoint has > been inserted. > > gdb/ > * infrun.h (clear_step_over_info): New prototype. > * infrun.c (thread_is_stepping_over_breakpoint): Move earlier > on. > (clear_step_over_info): Use it. Make external. > (resume_1, finish_step_over, handle_signal_stop) > (keep_going_stepped_thread, keep_going_pass_signal): Adjust > accordingly. > * thread.c (clear_thread_inferior_resources): Call > `clear_step_over_info'. This patch looks good to me, but I'd really prefer if Pedro could look at it, since he's much more adept in this area. Simon