From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id ECFBA383B425 for ; Mon, 7 Jun 2021 13:21:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org ECFBA383B425 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap.suse.de (imap-alt.suse-dmz.suse.de [192.168.254.47]) (using TLSv1.2 with cipher ECDHE-ECDSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 077351FDA5; Mon, 7 Jun 2021 13:21:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1623072090; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type; bh=hW1uNbtv3JkGeGcBiHFQm/vmHgcbpoXI0FuahtSvarU=; b=RZ+0+Sm1fct6zunNT/2ro7HxyeoU/GW+Vqnz5L53uURmBF6nlKuIaEsOJmd7ORUxIZtDhT cyPKfVDQV0orgeSQ3d0AGbPr8k9llKz/suRSDoCKC1yQRwB7YtaG7vJ6E9tcaNtrcNDduw /fl9QAKlQAOCH4o6iM5LWSleoRxLAdc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1623072090; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type; bh=hW1uNbtv3JkGeGcBiHFQm/vmHgcbpoXI0FuahtSvarU=; b=mtgXgFyEVT+eN091EQ7BanTrnjgX5b0g/YhagRmHberUornVgVqZmN/1kRlE6Ul0vkP0Qb kAAP4WnbcO+UX0Dw== Received: from imap3-int (imap-alt.suse-dmz.suse.de [192.168.254.47]) by imap.suse.de (Postfix) with ESMTP id D6F64118DD; Mon, 7 Jun 2021 13:21:29 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1623072090; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type; bh=hW1uNbtv3JkGeGcBiHFQm/vmHgcbpoXI0FuahtSvarU=; b=RZ+0+Sm1fct6zunNT/2ro7HxyeoU/GW+Vqnz5L53uURmBF6nlKuIaEsOJmd7ORUxIZtDhT cyPKfVDQV0orgeSQ3d0AGbPr8k9llKz/suRSDoCKC1yQRwB7YtaG7vJ6E9tcaNtrcNDduw /fl9QAKlQAOCH4o6iM5LWSleoRxLAdc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1623072090; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type; bh=hW1uNbtv3JkGeGcBiHFQm/vmHgcbpoXI0FuahtSvarU=; b=mtgXgFyEVT+eN091EQ7BanTrnjgX5b0g/YhagRmHberUornVgVqZmN/1kRlE6Ul0vkP0Qb kAAP4WnbcO+UX0Dw== Received: from director2.suse.de ([192.168.254.72]) by imap3-int with ESMTPSA id TGNyM1kdvmBUHgAALh3uQQ (envelope-from ); Mon, 07 Jun 2021 13:21:29 +0000 Date: Mon, 7 Jun 2021 15:21:28 +0200 From: Tom de Vries To: gdb-patches@sourceware.org Cc: Pedro Alves , Simon Marchi Subject: [RFC][gdb/doc] Document non-stop attach behaviour Message-ID: <20210607132127.GA10588@delia.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-11.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 07 Jun 2021 13:21:41 -0000 Hi, While investigating PR27908, I got confused about what the proper behaviour is when attaching to a multi-threaded program in non-stop mode. In particular, when running a script that issues an "info threads" after an attach in non-stop mode, it can show a non-current thread as still running: ... $ ./a.out & pid=$!; \ gdb -q \ -iex "set trace-commands on" \ -iex "set pagination off" \ -iex "set non-stop on" \ -p $pid \ -ex "info threads" [2] 10038 +set pagination off +set non-stop on Attaching to process 10038 [New LWP 10040] main () at test.c:37 37 while (1) +info threads Id Target Id Frame * 1 Thread 0x7f63547a8740 (LWP 10038) "a.out" main () at t.c:37 2 Thread 0x7f6353fd7700 (LWP 10040) "a.out" (running) (gdb) Thread 2 "a.out" stopped. thread_func (p=0x0) at test.c:13 13 while (1) ... An "info threads" after the 'Thread 2 "a.out" stopped' message will show it as stopped though: ... info threads +info threads Id Target Id Frame * 1 Thread 0x7f63547a8740 (LWP 10038) "a.out" main () at t.c:37 2 Thread 0x7f6353fd7700 (LWP 10040) "a.out" thread_func (p=0x0) at t.c:13 (gdb) ... In conclusion, it seems that attaching in non-stop mode stops all threads, just like in all-stop mode. But the stopping of non-current threads is visible to the user. Update the non-stop documentation to describe the attach behaviour in some detail. Any comments? Thanks, - Tom [gdb/doc] Document non-stop attach behaviour gdb/doc/ChangeLog: 2021-06-07 Tom de Vries * gdb.texinfo (Non-Stop Mode): Describe non-stop attach behaviour. --- gdb/doc/gdb.texinfo | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo index d09b86cda95..0fd7ab16150 100644 --- a/gdb/doc/gdb.texinfo +++ b/gdb/doc/gdb.texinfo @@ -6957,6 +6957,13 @@ one thread while allowing others to run freely, stepping one thread while holding all others stopped, or stepping several threads independently and simultaneously. +Note that attaching in non-stop mode stops all threads, just as in +all-stop mode. However, while in all-stop mode the attach command is +finished only once all threads are stopped, in non-stop mode it's +finished once the current thread is stopped. Consequently, it's +briefly possible to observe non-current threads still running after an +attach. + To enter non-stop mode, use this sequence of commands before you run or attach to your program: