From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id tcjUJAaiHmFnFgAAWB0awg (envelope-from ) for ; Thu, 19 Aug 2021 14:25:10 -0400 Received: by simark.ca (Postfix, from userid 112) id 885BF1EDFB; Thu, 19 Aug 2021 14:25:10 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 0ADD71E79C for ; Thu, 19 Aug 2021 14:25:09 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 5666739AE425 for ; Thu, 19 Aug 2021 18:25:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5666739AE425 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629397508; bh=4DmD1qt8FpV/Efx5DedFfYigfylbr7Paq1VlKtX1hQI=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=D6L9XgykaAaA30u7s/jKiR+gkp6Mtr8IlAGIXvSuLUsQ8NXPtw2x/4eMo3GOLvT+4 KHCy38gN1fLFrvY8QpmNUE9xoiLfcOz2AxLqjyitJ9/P3Ffu/pDskrz+oQKtSLhq8Q liM7MrauvbGr6Y+cSrbQgsxLhmV7679kMSvgrh7A= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 4F2E3385482F for ; Thu, 19 Aug 2021 18:23:41 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4F2E3385482F Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 17JINZ77031265 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Aug 2021 14:23:40 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 17JINZ77031265 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (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 EF8EE1E79C; Thu, 19 Aug 2021 14:23:34 -0400 (EDT) Subject: Re: [PATCH] Fix displaced stepping watchpoint check order To: Luis Machado , gdb-patches@sourceware.org References: <20210608154230.354202-1-luis.machado@linaro.org> <9c697f35-1059-5ea8-83c3-ea75fcc95b32@polymtl.ca> <0ef1ceef-f6b4-7310-bec0-d54d4b646fea@linaro.org> <18bc6e10-91e5-15c9-0455-30004d82b7c8@polymtl.ca> <67e5fcec-2a29-9640-355c-104f5ea03c7a@linaro.org> Message-ID: <79afff97-c28f-1964-0b6c-c2ea9672e5df@polymtl.ca> Date: Thu, 19 Aug 2021 14:23:34 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 MIME-Version: 1.0 In-Reply-To: <67e5fcec-2a29-9640-355c-104f5ea03c7a@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Thu, 19 Aug 2021 18:23:35 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" > Although hardware watchpoints are usually per-thread, I don't think GDB handles it in that level of detail. It seems to mostly ignore insertion of hardware watchpoints if we're trying to step over a PC that caused a hardware watchpoint trigger. > > See, for example, breakpoint.c:should_be_inserted > > /* Don't insert watchpoints if we're trying to step past the > instruction that triggered one. */ > if ((bl->loc_type == bp_loc_hardware_watchpoint) > && stepping_past_nonsteppable_watchpoint ()) > { > infrun_debug_printf ("stepping past non-steppable watchpoint. " > "skipping watchpoint at %s:%d\n", > paddress (bl->gdbarch, bl->address), bl->length); > return 0; > } > > From what I recall, GDB replicates the hardware watchpoints to all threads, so disabling all hardware watchpoints for all threads (actually not inserting them) makes sense. GDB doesn't try to add thread-specific hardware watchpoints at the moment. > > Having per-thread hardware watchpoints might be desirable in some cases, but it may complicate the user interaction a bit. > > I haven't investigated if GDB, during a step-over operation, keeps threads running with hardware watchpoints disabled. If it doesn't handle it correctly, we may miss hardware watchpoints hits, unless GDB serializes the step-overs. That's where I was going too. Just imagine in non-stop, you have many threads running, one hits the watchpoint. You then want to resume that thread, that requires stepping over the watchpoint while other threads are running. If the watchpoint was really removed for all running threads, a running thread could miss it. But watchpoints aren't like memory breakpoints, they are usually set using debug register, which are per-thread, so you can't really remove a watchpoint from a running thread... that's why I was thinking that maybe the watchpoint was only removed for the thread stepping over the watchpoint. But maybe not. > "Presently GDB can only step over one breakpoint at any given time." There can be only one in-line step at a time. But there can be multiple displaced steps at a time (since somewhat recently). There can't be an in-line step at the same time as some displaced steps. While an in-line step is in progress, it is guaranteed that there are no other running threads. Reading keep_going_pass_signal, I might understand that watchpoints are always stepped using the in-line mechanism, while all other threads are stopped. I would have to try it. Simon