From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 8016F384B808 for ; Thu, 21 Jul 2022 18:21:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8016F384B808 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)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 3039D1E21F; Thu, 21 Jul 2022 14:21:14 -0400 (EDT) Message-ID: <810c3236-c22b-83a4-7214-90eebf490910@simark.ca> Date: Thu, 21 Jul 2022 14:21:13 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0 Subject: Re: [PATCH v2 19/29] stop_all_threads: (re-)enable async before waiting for stops Content-Language: en-US To: Pedro Alves , gdb-patches@sourceware.org References: <20220713222433.374898-1-pedro@palves.net> <20220713222433.374898-20-pedro@palves.net> From: Simon Marchi In-Reply-To: <20220713222433.374898-20-pedro@palves.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 21 Jul 2022 18:21:15 -0000 > @@ -5177,6 +5179,83 @@ handle_one (const wait_one_event &event) > return false; > } > > +/* Helper for stop_all_threads. wait_one waits for events until it > + sees a TARGET_WAITKIND_NO_RESUMED event. When it sees one, it > + disables target_async for the target to stop waiting for events > + from it. TARGET_WAITKIND_NO_RESUMED can be delayed though, > + consider, debugging against gdbserver: > + > + #1 - Threads 1-5 are running, and thread 1 hits a breakpoint. > + > + #2 - gdb processes the breakpoint hit for thread 1, stops all > + threads, and steps thread 1 over the breakpoint. while > + stopping threads, some other threads reported interesting > + events, which were left pending in the thread's objects > + (infrun's queue). > + > + #2 - Thread 1 exits (it stepped an exit syscall), and gdbserver > + reports the thread exit for thread 1. The event ends up in > + remote's stop reply queue. > + > + #3 - That was the last resumed thread, so gdbserver reports > + no-resumed, and that event also ends up in remote's stop > + reply queue, queued after the thread exit from #2. I don't understand this part: why did gdbserver report two events here? Why does it report a no-resumed event after reporting the thread-exited event? Simon