From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id 00ABA3858400 for ; Thu, 26 Aug 2021 10:08:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 00ABA3858400 Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id EE5EA21E4D; Thu, 26 Aug 2021 10:08:25 +0000 (UTC) Received: from imap1.suse-dmz.suse.de (imap1.suse-dmz.suse.de [192.168.254.73]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap1.suse-dmz.suse.de (Postfix) with ESMTPS id D71131364E; Thu, 26 Aug 2021 10:08:25 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap1.suse-dmz.suse.de with ESMTPSA id rhNxMxloJ2E2JQAAGKfGzw (envelope-from ); Thu, 26 Aug 2021 10:08:25 +0000 Subject: Re: [RFC][gdb/doc] Document non-stop attach behaviour To: Simon Marchi , gdb-patches@sourceware.org Cc: Pedro Alves References: <20210607132127.GA10588@delia.home> <413e84be-8827-53fb-cd6f-e2ecc66a4af2@polymtl.ca> From: Tom de Vries Message-ID: <5a80535d-f7ae-4707-4df5-5efff08e389d@suse.de> Date: Thu, 26 Aug 2021 12:08:25 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <413e84be-8827-53fb-cd6f-e2ecc66a4af2@polymtl.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-13.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Thu, 26 Aug 2021 10:08:37 -0000 On 8/26/21 4:55 AM, Simon Marchi wrote: > > > On 2021-06-07 9:21 a.m., Tom de Vries wrote: >> 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: >> >> > > I think your patch describes well the current behaviour of GDB, so > that's good. > > I think the behavior could be a bit more user friendly, we could wait > for all the attached program's threads to have reported their stop > before showing the prompt. Same with the interrupt (with and without > "-a") command, we know which threads we expect to become stopped, we > could wait for them to be stopped before giving back the prompt. That > would make it easier for scripts: when the attach / interrupt command > returns, you know the attached / interrupted threads are stopped and can > be inspected. Ack, I can file a PR for that. So, should I apply the doc patch, or is it f.i.i too trivial to mention? Thanks, - Tom