From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id yZU/Eqt2fGqsliAAWB0awg (envelope-from ) for ; Wed, 12 Aug 2026 09:35:39 -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=Va+TTv2P; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4588A1E033; Wed, 12 Aug 2026 09:35:39 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.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 autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::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 60E301E033 for ; Wed, 12 Aug 2026 09:35:38 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id EA1F74BB24FD for ; Wed, 12 Aug 2026 13:35:37 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EA1F74BB24FD 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=Va+TTv2P Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by sourceware.org (Postfix) with ESMTPS id E064A4BB3BA3 for ; Wed, 12 Aug 2026 13:29:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E064A4BB3BA3 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 E064A4BB3BA3 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=192.198.163.9 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786541379; cv=none; b=HUNbNxjh5fgH15wqVF7LL5ZL+xS0y2aRGImvxhUZMhKxekfPiKlPoSkYbXDsVdvoUTWtYuQqh5OlkZu/jATuS12nHjmqNuruVqoRthqBv4Y3bSrBS7r04c3JzqwvL58ctzL0PETS9LzMWEm/CrNSxcHHlPeKl359vsDjM+NZhJA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1786541379; c=relaxed/simple; bh=TTsclyV4s/RkuZchdhl1Pf+fOICrdcvF+9+dJ1OICo0=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=d6VbI22vEOqGCQfwED/YceoI06qztcWZEVaAEs/HyKsds8mpdIbWWo+B/t1A9gZx7WPzBw/PWjuHEuQQ2O1WdsHAFWvGBn28mJYBO+qT3JsUfL9uCjxKo0KCEjxProYwfOC/k5roEJ4rvil9kvkV60UBgD0w5jYvSl39D6q0How= 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=Va+TTv2P DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E064A4BB3BA3 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1786541379; x=1818077379; h=from:to:subject:date:message-id:in-reply-to:references: mime-version:content-transfer-encoding; bh=TTsclyV4s/RkuZchdhl1Pf+fOICrdcvF+9+dJ1OICo0=; b=Va+TTv2Pv+PBcKT90rWDRpZ0pDhqPiEBeveNlcybMQNi/HW0rSG7svmw mXOHKYfS1z1rrTnT9RZlHcNZ/xpXzfnjqlGMy+S/YEOTzR/qvTfaiotz6 BhXfK6orKXxJxMwDjSoHpquG83Zoja81Wq4DzdBdkeWayP+mPB87znIjW 4IILXRP1bVMSM4w61jrYdNPxMNo/hOvv3/TKaM3qmprqygGQG80pJEl6q dfRb7FkXpgfC4poGzWBhOb8kAuQBHoUf9UEDn0PsoFEDHEzMA0Ig3sHrC jF6Qiht4q5AEpA+1Cpj2pEcD7o64DsSzLfkR37j3g8ajlsxPcDZZc6TNT w==; X-CSE-ConnectionGUID: Qpq/+90lRCSVPfUjuRsj6A== X-CSE-MsgGUID: VJpyOWq6Q4CyLtokv6bq3A== X-IronPort-AV: E=McAfee;i="6800,10657,11872"; a="97757897" X-IronPort-AV: E=Sophos;i="6.25,219,1779174000"; d="scan'208";a="97757897" Received: from fmviesa010.fm.intel.com ([10.60.135.150]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Aug 2026 06:29:38 -0700 X-CSE-ConnectionGUID: 2tjUfNJmQq60oMO9dgEvbQ== X-CSE-MsgGUID: 1BctbNlRTSi+XYX4Uvj+lA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,219,1779174000"; d="scan'208";a="259817958" Received: from gkldtt-dev-004.igk.intel.com (HELO localhost) ([10.123.221.202]) by fmviesa010-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 12 Aug 2026 06:29:37 -0700 From: Markus Metzger To: gdb-patches@sourceware.org Subject: [PATCH v4 29/44] gdb, remote: allow deleting the last thread in inferior in update_thread_list() Date: Wed, 12 Aug 2026 15:27:49 +0200 Message-ID: <20260812132805.380163-30-markus.t.metzger@intel.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260812132805.380163-1-markus.t.metzger@intel.com> References: <20260812132805.380163-1-markus.t.metzger@intel.com> 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 We do want to support inferiors without threads, e.g. for GPU inferiors that may not have any thread when no work is dispatched to that GPU but that may get new threads again when new work is dispatched. The test (added in a subsequent patch) gdb.arch/intelgt-interrupt-exited-thread.exp resumes a single GPU thread with scheduler-locking on and then interrupts the target with C-c. The GPU thread meanwhile finished its dispatch, so when the target interrupts the device, it does not respond. In response to vCtrlC, gdbserver-intelgt sends %Stop:N to indicate that nothing is running on the device anymore. GDB receives the notification. In handle_no_resumed(), GDB updates the thread list. In this scenario, the thread that GDB had resumed was the last thread on the device, so the thread list is now empty. If we're not deleting that thread, handle_no_resumed() will ignore the event since it found a resumed thread, and we're stuck. To the user, it would appear as if GDB were hanging. Interrupting the target with C-c does not have any effect and there is no way to get the prompt back. This patch causes regressions in gdb.replay/missing.thread.exp When the replay log is updated to remove all threads like this w $qXfer:threads:read::0,1000#92 r $l\n\n#68 GDB removes the thread and no longer interacts with it, so replay fails at the subsequent w $QThreadOptions;0#00 r $OK#9a This patch removes that part of the test. --- gdb/remote.c | 20 --------------- gdb/testsuite/gdb.replay/missing-thread.exp | 28 +++------------------ 2 files changed, 3 insertions(+), 45 deletions(-) diff --git a/gdb/remote.c b/gdb/remote.c index 5721e791612..10bceb2c798 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -4479,18 +4479,6 @@ remote_target::remote_get_threads_with_qthreadinfo (threads_listing_context *con return 0; } -/* Return true if INF only has one non-exited thread. */ - -static bool -has_single_non_exited_thread (inferior *inf) -{ - int count = 0; - for (thread_info &tp ATTRIBUTE_UNUSED : inf->non_exited_threads ()) - if (++count > 1) - break; - return count == 1; -} - /* Implement the to_update_thread_list function for the remote targets. */ @@ -4526,14 +4514,6 @@ remote_target::update_thread_list () for (thread_info &tp : all_threads_safe (this)) if (!context.contains_thread (tp.ptid)) { - /* Do not remove the thread if it is the last thread in - the inferior. This situation happens when we have a - pending exit process status to process. Otherwise we - may end up with a seemingly live inferior (i.e. pid - != 0) that has no threads. */ - if (has_single_non_exited_thread (tp.inf)) - continue; - /* Do not remove the thread if we've requested to be notified of its exit. For example, the thread may be displaced stepping, infrun will need to handle the diff --git a/gdb/testsuite/gdb.replay/missing-thread.exp b/gdb/testsuite/gdb.replay/missing-thread.exp index 23bbddac556..a27a0181c7f 100644 --- a/gdb/testsuite/gdb.replay/missing-thread.exp +++ b/gdb/testsuite/gdb.replay/missing-thread.exp @@ -83,10 +83,7 @@ proc_with_prefix record_initial_logfile { log_filename } { # The line to be modified is the last ... line, this is # the reply from the remote that indicates the thread list. It is expected # that the thread list will contain two threads. -# -# When DROP_BOTH is true then both threads will be removed from the modified -# line. Otherwise, only the second thread is removed. -proc update_replay_log { in_filename out_filename drop_both } { +proc update_replay_log { in_filename out_filename } { # Read IN_FILENAME into a list. set fd [open $in_filename] set data [read $fd] @@ -108,11 +105,7 @@ proc update_replay_log { in_filename out_filename drop_both } { set fixed_log false if {[regexp "^(r .*\\\\n)(\\\\n)(\\\\n)(.*)$" $line \ match part1 part2 part3 part4]} { - if { $drop_both } { - set line $part1$part4 - } else { - set line $part1$part2$part4 - } + set line $part1$part2$part4 set lines [lreplace $lines $idx $idx $line] set fixed_log true } @@ -192,18 +185,13 @@ proc run_test { non_stop } { # The replay log is placed in 'replay.log'. set remote_log [standard_output_file replay${suffix}.log] set missing_1_log [standard_output_file replay-missing-1${suffix}.log] - set missing_2_log [standard_output_file replay-missing-2${suffix}.log] record_initial_logfile $remote_log - if { ![update_replay_log $remote_log $missing_1_log false] } { + if { ![update_replay_log $remote_log $missing_1_log] } { fail "couldn't update remote replay log (drop 1 case)" } - if { ![update_replay_log $remote_log $missing_2_log true] } { - fail "couldn't update remote replay log (drop 2 case)" - } - with_test_prefix "with unmodified log" { # Replay with the unmodified log. This confirms that we can replay this # scenario correctly. @@ -216,16 +204,6 @@ proc run_test { non_stop } { # error when the inferior stops. replay_with_log $missing_1_log true $non_stop } - - with_test_prefix "missing 2 threads log" { - # When we drop both threads from the reply, GDB doesn't - # actually remove both threads from the inferior; an inferior must - # always have at least one thread. So in this case, as the primary - # thread is first, GDB drops this, then retains the second thread, which - # is the one we're stopping in, and so, we don't expect to see the error - # in this case. - replay_with_log $missing_2_log false $non_stop - } } # Run the test twice, with non-stop on and off. -- 2.43.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.