From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id oTzIBSE2vmrsLCMAWB0awg (envelope-from ) for ; Thu, 01 Oct 2026 06:29:53 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=mA1//37F; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id BBC0C1E04E; Thu, 01 Oct 2026 06:29:52 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=unavailable autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 017F91E04E for ; Thu, 01 Oct 2026 06:29:37 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 29A014BB5930 for ; Thu, 1 Oct 2026 10:29:36 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 29A014BB5930 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=mA1//37F Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.14]) by sourceware.org (Postfix) with ESMTPS id 637E04BB58ED for ; Thu, 1 Oct 2026 10:28:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 637E04BB58ED Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=intel.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 637E04BB58ED Authentication-Results: sourceware.org; arc=none smtp.remote-ip=192.198.163.14 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790850531; cv=none; b=dg+HKpAxiH0OYoJj+PzGuE4H+lfIweWYdi0UCqJiqPY4D3E4u3MKTZqA4hh3b/KQVMVr/ys13ph4PaDIaAh5rSj05fnlA6aeyxd5Ptznan2VJwMpV+xr6P8RLavdRovTiv0537XPE5tZtfqfbiwwCduOp6RATZ9xjjewN9OpoPw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1790850531; c=relaxed/simple; bh=yoZE7/BLuKHTdqHFOh8kGBwXYM6/G71EwvyL0rzg76Y=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=HdWVFKdDHNrrvy6vtN8/G0vGHPSLw7iXhwhhWX6c4ehWL1MmQNXrVor5u1k1LYvi3iET1oCDjNDo1mFqmdwk3riqAf92V/p5HyA84QIxCTZ+Ran7gXF2WtiiEVRV+OQL95PE45JHITSUQARokiyw8aAoYpZlOlgIE5Jdqba8XXc= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=intel.com header.i=@intel.com header.a=rsa-sha256 header.s=Intel header.b=mA1//37F DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 637E04BB58ED DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1790850532; x=1822386532; h=from:to:subject:date:message-id:mime-version: content-transfer-encoding; bh=yoZE7/BLuKHTdqHFOh8kGBwXYM6/G71EwvyL0rzg76Y=; b=mA1//37Fdf0PSAN5O8AxUN9uExhA6PTrQmIdUZrQBCfuJ20FSYOB0hA2 R35Dfcbt1+x5rQSBGUmhhHfUOdV9excbDYXmS3j6V989Kq1L9ciKC3vD+ AxD3A5kgSYrS/RRYy5aMyn/LqE9KYmLKKBFWgUebhbWpxfJ6dvKMkfgEo hY0UqtE9OTHQO22gXHqNmvZ6y5T5vIBT/h47g6poumfki3E01EOHvb5gP vPxg14+AOXtmVT5OgrufH3xWZv9y8fT4vQqUnSboE7TCVkDTjHbX+MWcp 3MIVvYRNKlergarZqDk7C41zFKEaJH52cjqlm36kxNlt/rPG8yTu0/g8d w==; X-CSE-ConnectionGUID: 7rpKD+5wRTulhwgqVrouVA== X-CSE-MsgGUID: 6e+cNaFzTU2ya/9ehri0bA== X-IronPort-AV: E=McAfee;i="6800,10657,11921"; a="91619599" X-IronPort-AV: E=Sophos;i="6.27,134,1787036400"; d="scan'208";a="91619599" Received: from fmviesa003.fm.intel.com ([10.60.135.143]) by fmvoesa108.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Oct 2026 03:28:50 -0700 X-CSE-ConnectionGUID: ryAPQvjyRKC+X1nfyZKKog== X-CSE-MsgGUID: YbeP5eRBRem4O3nv2pM3kA== X-ExtLoop1: 1 Received: from gkldtt-dev-004.igk.intel.com (HELO localhost) ([10.123.221.202]) by fmviesa003-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Oct 2026 03:28:49 -0700 From: Markus Metzger To: gdb-patches@sourceware.org Subject: [RFC PATCH 0/8] breakpoint handling Date: Thu, 1 Oct 2026 12:28:39 +0200 Message-ID: <20261001102847.576880-1-markus.t.metzger@intel.com> X-Mailer: git-send-email 2.53.0 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org This RFC consists of three parts. The first part gdb, infrun: do not discard a step-completed pending waitstatus was submitted as patch[1]. It fixes a bug[2] with breakpoints on adjacent instructions getting skipped during step-over. Discussion[3] on the patch and further investigation revealed an issue with stepping over newly inserted breakpoints at the current location after switching to a thread that just completed a step-over, e.g. (gdb) thread (gdb) break (gdb) continue would now hit the breakpoint, whereas GDB's normal behavior is to step the current thread over breakpoints at the current location. The issue is the extra step completed event that we're no longer discarding, which is mis-interpreted as having completed the step-over at the current location. Thread A completed a step-over, but GDB chose to present another event at thread B to the user. Thread A's event used to be discarded, but is now saved as pending event. When the user switches to thread A, inserts a breakpoint, and continues, proceed() finds the breakpoint at the current location and starts a step-over. When it resumes thread A, it is not resumed on the target and the pending event is reported instead. We're still at the same location and the breakpoint is still there, and GDB now reports that we hit that breakpoint. GDBs behavior is inconsistent in that regard, because (gdb) break (gdb) thread (gdb) continue will make the thread we switched away from hit the breakpoint, whereas (gdb) break (gdb) continue will skip the breakpoint (at least for the current thread). The second part gdb, infrun: track last waitstatus per thread gdb, infrun: simplify print_stop_location() gdb, thread: simplify print_selected_thread_frame() gdb, interp: repeat stop event when switching threads gdb, infrun: handle stop event when selecting a thread tries to perserve the current behavior, i.e. step the current thread over a newly inserted breakpoint at the current location, by handling pending events already when selecting a thread. It also prints the last stop notification for the selected thread, which could be considered an improvement on its own. In the above scenario, the pending step completed event would already be handled when switching to that thread. Any breakpoint that is already inserted at that location would be reported, including any breakpoints that were added between the thread stopping and switching to it. When we now insert a breakpoint and continue, there is no pending event and the step-over succeeds (unless the step completes without making progress for some other reason, of course). The third part gdb, infrun: inline init_thread_stepping_state() gdb, infrun: only step over breakpoints that were hit makes GDB's breakpoint behavior more consistent. It only steps over breakoints that were actually hit. This makes (gdb) set $pc = 0xf00 (gdb) continue behave similar to (gdb) jump 0xf00 and it will hit the breakpoint inserted by (gdb) break With respect to the latter, while the second part tries to preserve the current behavior, the thrid part intentionally changes it, so we would probably pick one or the other direction. Or an entirely different one. [1]: https://sourceware.org/pipermail/gdb-patches/2026-September/230359.html [2]: https://sourceware.org/bugzilla/show_bug.cgi?id=34380 [3]: https://sourceware.org/pipermail/gdb-patches/2026-September/230527.html Markus Metzger (8): gdb, infrun: do not discard a step-completed pending waitstatus gdb, infrun: track last waitstatus per thread gdb, infrun: simplify print_stop_location() gdb, thread: simplify print_selected_thread_frame() gdb, interp: repeat stop event when switching threads gdb, infrun: handle stop event when selecting a thread gdb, infrun: inline init_thread_stepping_state() gdb, infrun: only step over breakpoints that were hit gdb/cli/cli-interp.c | 29 +++++- gdb/gdbthread.h | 3 + gdb/infcmd.c | 10 +- gdb/infrun.c | 111 +++++++++------------- gdb/infrun.h | 4 + gdb/mi/mi-interp.c | 42 ++++++-- gdb/testsuite/gdb.threads/adjacent-bp.c | 48 ++++++++++ gdb/testsuite/gdb.threads/adjacent-bp.exp | 86 +++++++++++++++++ gdb/thread.c | 27 ++++-- 9 files changed, 269 insertions(+), 91 deletions(-) create mode 100644 gdb/testsuite/gdb.threads/adjacent-bp.c create mode 100644 gdb/testsuite/gdb.threads/adjacent-bp.exp -- 2.53.0 ________________________________________ Intel Deutschland GmbH Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany Tel: +49 (89) 99143-0 www.intel.de Managing Directors: Candice Moore, Jeffrey Schneiderman, Ramachandran Sitaraman Chairperson of the Supervisory Board: Sonja Pierer Registered Seat: Munich Commercial Register B: Amtsgericht Munich HRB 186928 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.