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 8181B383F87E for ; Fri, 15 May 2020 16:06:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 8181B383F87E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark@simark.ca Received: from [10.0.0.188] (unknown [192.222.164.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 484B31E79B; Fri, 15 May 2020 12:06:26 -0400 (EDT) Subject: Re: [PATCH v2] gdb: infrun: consume multiple events at each pass in stop_all_threads To: Pedro Alves , "Aktemur, Tankut Baris" , Simon Marchi , "gdb-patches@sourceware.org" Cc: Laurent Morichetti References: <20200224193638.29578-1-simon.marchi@efficios.com> <8402549f-c733-cb8b-918c-4dfb06eeb7a0@redhat.com> <80775539-f358-874b-df16-1e8642e082ca@simark.ca> <5ac9bb7a-6bf0-401f-909e-54d98739685b@palves.net> From: Simon Marchi Message-ID: Date: Fri, 15 May 2020 12:06:25 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <5ac9bb7a-6bf0-401f-909e-54d98739685b@palves.net> Content-Type: text/plain; charset=utf-8 Content-Language: tl Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_PASS, 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: Fri, 15 May 2020 16:06:29 -0000 On 2020-05-14 2:14 p.m., Pedro Alves wrote: > On 5/14/20 7:02 PM, Simon Marchi wrote: > >> Here's a rebased version. > > Thanks Simon. Please go ahead and merge. > > BTW, did you consider coming up with a mechanism similar to > make_scoped_defer_target_commit_resume()/target_commit_resume() > for target_stop, so that we could coalesce the multiple vCont;t > requests in a single remote packet? That could also cut down > on latency. > > (gdbserver's resume interface is better for that, in that > a stop, continues and steps all go via the same interface: > > static void > resume (struct thread_resume *actions, size_t num_actions) > { > > I've pondered adjusting GDB's resume interface in a similar > way. That would make target_commit_resume Just Work for > stops too. > ) No, I haven't considered it, but I think I see what you mean. To illustrate this case using the remote target, I had to set "maintenance set target-non-stop on", while using "target non-stop off". Am I missing something, is there a more common scenario where it gets called, using the remote target? With the above, when hitting a breakpoint, I do see the stops sent in sequence as part of stop_all_threads: Sending packet: $vCont;t:p25a703.25a71c#86...Packet received: OK Sending packet: $vCont;t:p25a703.25a71d#87...Packet received: OK Sending packet: $vCont;t:p25a703.25a71e#88...Packet received: OK Sending packet: $vCont;t:p25a703.25a71f#89...Packet received: OK Sending packet: $vCont;t:p25a703.25a720#54...Packet received: OK which could easily be coalesced. I think a `target_commit_stop` approach that mimics `target_commit_resume` would work, without being too invasive. But maybe changing the `target_stop` interface to accept multiple ptids would be a better approach for the future, since it's more of a step towards the gdbserver-style interface that you talked about. In stop_all_threads, it would be quite easy to use: build a vector of ptid in this loop: 4815 /* Go through all threads looking for threads that we need 4816 to tell the target to stop. */ 4817 for (thread_info *t : all_non_exited_threads ()) and call target_stop once after the loop. Simon