From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by sourceware.org (Postfix) with ESMTPS id B0FF8384E788 for ; Mon, 12 Dec 2022 20:18:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B0FF8384E788 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=palves.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wr1-f43.google.com with SMTP id h11so13378106wrw.13 for ; Mon, 12 Dec 2022 12:18:44 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:content-language:in-reply-to:mime-version :user-agent:date:message-id:references:to:subject:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=tFpu0pEIlTr78kEzOkwqdIB8mMl44RgkwXQ1VzbWz1s=; b=MoU37f0sIOnc5AcfcnpBAPz4QPwyVnNv5pT1IPGnFhHDKvwSne77axslv6g3POAQJ6 //ZJ/sDJAUJEbj4AwC+ytPW2p7+cKcHmHPz019BtJ2RRgcZ6Eq282kmZRhTx2G/4Hxsj 1hQbRGez8f8KMdknF8lseHjRlb5JMRtjxLiimaY3HUXjxU5RyuOovxHb3P92QDEcXLWS Zissm8GO6ThDBIBlz2ZLz+qdnUARtQPKYKWeMTTH1zjoJ8hOxp/sGSXFpZExi+pg5Sfw VjNk4kXspIxr5PFkKs2dNxC5NldBUiQ1OC1mb3ZtBZvMeDmsedVWoE//J4elDDtjqaM9 lh5A== X-Gm-Message-State: ANoB5pnwmwEJigTW75OHTnTNkrHAHJIPiUfTBSlMYCAoWrLCYMuEbNrI wbzn1bBYsvOzxm7ZK+EgZRrjZVOsFq6o6w== X-Google-Smtp-Source: AA0mqf69RCHAaLgbTBX51vWii+JP0GhaxFvYcJ6bH4PfFIuvrcmg9LIoatneY5MN5oCzEhynIakw7A== X-Received: by 2002:a05:6000:1e0f:b0:24e:ca7b:acc0 with SMTP id bj15-20020a0560001e0f00b0024eca7bacc0mr5389872wrb.18.1670876323546; Mon, 12 Dec 2022 12:18:43 -0800 (PST) Received: from ?IPv6:2001:8a0:f912:6700:afd9:8b6d:223f:6170? ([2001:8a0:f912:6700:afd9:8b6d:223f:6170]) by smtp.gmail.com with ESMTPSA id w8-20020a5d5448000000b0022584c82c80sm9637895wrv.19.2022.12.12.12.18.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 12 Dec 2022 12:18:43 -0800 (PST) From: Pedro Alves Subject: Re: [PATCH v2 19/29] stop_all_threads: (re-)enable async before waiting for stops To: Simon Marchi , gdb-patches@sourceware.org References: <20220713222433.374898-1-pedro@palves.net> <20220713222433.374898-20-pedro@palves.net> <810c3236-c22b-83a4-7214-90eebf490910@simark.ca> Message-ID: <61200e77-c67d-5f4e-ceb2-37d8ff61e4a2@palves.net> Date: Mon, 12 Dec 2022 20:18:48 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <810c3236-c22b-83a4-7214-90eebf490910@simark.ca> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2022-07-21 7:21 p.m., Simon Marchi wrote: >> @@ -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? gdbserver is tweaked to do that in the next patch: "[PATCH v2 20/29] gdbserver: Queue no-resumed event after thread exit" If we didn't do that, then gdb would be forced to check whether the thread that exited was the last one in non-stop mode, which would mean a a thread list sync for every thread exit event. Making sure to queue a no-resumed event is a lot more efficient.