From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-2.mimecast.com [205.139.110.61]) by sourceware.org (Postfix) with ESMTP id 428EE385DC1C for ; Fri, 15 May 2020 16:15:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 428EE385DC1C Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-172-IFV1YNfvNFaYWCPCA0ULfA-1; Fri, 15 May 2020 12:15:10 -0400 X-MC-Unique: IFV1YNfvNFaYWCPCA0ULfA-1 Received: by mail-wm1-f70.google.com with SMTP id t62so1004701wmt.7 for ; Fri, 15 May 2020 09:15:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=94uFZk/MUSscA0bns2u/0GguDYIOGoUxkt9pB6EJxR0=; b=n2AZJGuGfMBBfQXgEC+aG99ht4C9dZlrzAYVLdWIhLXzERhKZ1hUpIpumB1tsMzFf1 7FuLUsh9zXBoIOk34uhAym7SJ6hMqI4/3ZUsSPCrneI5cqOOweTdG3/loVj0U8ZBD5ux 2AyvYET6LvF+89K4peSCKaRzEMaSMmWa/SZe8YTlAapVqkc1Mgwihig0GsS7oXYor44P c5j0DwZoAoYuvKd3wHO74oYJHroC+TOCCDKBKrvCAwx+Fyp4MYozmQn/PPxbCzCQpf69 hsPAqupMEfGlPTQOLAMHJMxdoMRXxkYrtpL3XTWLopY927hiZuEcE4ZeSUF8L4+Y6AEj Iv0Q== X-Gm-Message-State: AOAM530s8ipPXERGv6Ej8tTt7CeoQmdkjyi697VUCpKj0k2yXUXW6GmG t7tBKZkRJ1KCrgfLhLb+LDYhYxzgsVxFbAufQUG+Phyv+Pr+3Bfn+sLdYtrjSCIuDNoO1dZdF0i SjXrxJ/DPpLtbbmeV78ONbQ== X-Received: by 2002:adf:f1c3:: with SMTP id z3mr5351833wro.201.1589559309749; Fri, 15 May 2020 09:15:09 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyhvpTcPZ0O/kaJyHePY+wmWqJJuANoIJem9Ah/SODa2a7Zv9JvNJgL3qnKdnWSe/kcskn3Ww== X-Received: by 2002:adf:f1c3:: with SMTP id z3mr5351808wro.201.1589559309503; Fri, 15 May 2020 09:15:09 -0700 (PDT) Received: from ?IPv6:2001:8a0:f909:7b00:56ee:75ff:fe8d:232b? ([2001:8a0:f909:7b00:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id r6sm17637645wmh.1.2020.05.15.09.15.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 15 May 2020 09:15:08 -0700 (PDT) Subject: Re: [PATCH v2] gdb: infrun: consume multiple events at each pass in stop_all_threads To: Simon Marchi , "Aktemur, Tankut Baris" , Simon Marchi , "gdb-patches@sourceware.org" 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> Cc: Laurent Morichetti From: Pedro Alves Message-ID: <7633fb1e-c966-5974-cc67-9c4e7769ff6f@redhat.com> Date: Fri, 15 May 2020 17:15:07 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-8.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, 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: Fri, 15 May 2020 16:15:29 -0000 On 5/15/20 5:06 PM, Simon Marchi wrote: > 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". I think you meant "set non-stop off" in the last command. > Am I missing something, is there a more common scenario where > it gets called, using the remote target? Nope, not missing it -- ideally "maintenance set target-non-stop" would default to "on", but we're not there yet, unfortunately. > > 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 Exactly. > > 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. I actually forgot you're looking at a native-only target. But even then, it may help if the debug API level can aggregate stop requests. Otherwise, it probably wouldn't help you. Thanks, Pedro Alves