From patchwork Fri Oct 28 14:01:44 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Pedro Alves X-Patchwork-Id: 9402031 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 121B2601C0 for ; Fri, 28 Oct 2016 14:02:42 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 047782A759 for ; Fri, 28 Oct 2016 14:02:42 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id EC1162A7CB; Fri, 28 Oct 2016 14:02:41 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=2.0 tests=BAYES_00,RCVD_IN_DNSWL_HI autolearn=ham version=3.3.1 Received: from lists.gnu.org (lists.gnu.org [208.118.235.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 71A3A2A759 for ; Fri, 28 Oct 2016 14:02:41 +0000 (UTC) Received: from localhost ([::1]:49300 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c07k0-0006Ep-Lu for patchwork-qemu-devel@patchwork.kernel.org; Fri, 28 Oct 2016 10:02:40 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59580) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c07jI-0005wQ-5B for qemu-devel@nongnu.org; Fri, 28 Oct 2016 10:02:00 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c07jC-0005VQ-Cn for qemu-devel@nongnu.org; Fri, 28 Oct 2016 10:01:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35532) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c07jC-0005Ua-5S for qemu-devel@nongnu.org; Fri, 28 Oct 2016 10:01:50 -0400 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C281C91C20; Fri, 28 Oct 2016 14:01:48 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9SE1iUh024477; Fri, 28 Oct 2016 10:01:45 -0400 To: Claudio Imbrenda , Christian Borntraeger , qemu-devel@nongnu.org References: <1476445983-16661-1-git-send-email-imbrenda@linux.vnet.ibm.com> <1476445983-16661-3-git-send-email-imbrenda@linux.vnet.ibm.com> <6ff5fd4e-d371-f204-371a-07edcb545e93@redhat.com> <91243842-10e9-666b-83e8-e271322371f7@linux.vnet.ibm.com> From: Pedro Alves Message-ID: <77a33e01-6293-8112-7fe2-4790ca13f736@redhat.com> Date: Fri, 28 Oct 2016 15:01:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <91243842-10e9-666b-83e8-e271322371f7@linux.vnet.ibm.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 28 Oct 2016 14:01:48 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 Subject: Re: [Qemu-devel] [PATCH v2 2/2] gdbstub: Fix vCont behaviour X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , Paolo Bonzini Errors-To: qemu-devel-bounces+patchwork-qemu-devel=patchwork.kernel.org@nongnu.org Sender: "Qemu-devel" X-Virus-Scanned: ClamAV using ClamSMTP On 10/28/2016 02:35 PM, Claudio Imbrenda wrote: > On 27/10/16 13:40, Pedro Alves wrote: >> I'm not a qemu gdbstub expert, but FYI, seeing this reminded me to push >> to gdb's master a (getting old) gdb patch that clarifies how vCont actions >> should be interpreted: >> >> https://sourceware.org/ml/gdb-patches/2016-02/msg00493.html >> >> It's already live at: >> >> https://sourceware.org/gdb/current/onlinedocs/gdb/Packets.html >> >> (The "already running" case is for non-stop mode, which qemu >> probably doesn't support.) > > From the new specifications I seem to understand that if I specify a > default as first action, then no further actions will be considered, > since it matches all threads? Right. > > e.g. vCont;c;s:1 will ignore the s:1 because the c was specified > earlier and it matches all threads, and therefore it's the leftmost > match? do I understand correctly? Yes. Note that GDB never ever sent a vCont like that. It's always put the default action last. So in practice, it doesn't change any behavior. OTOH, stubs can be simpler, given there's no need to special-case the default action. (Also, with this definition we can safely break a big vCont packet in multiple smaller ones, in non-stop mode: vCont;s:1;c == vCont;s:1 + vCont;c vCont;c;s:1 == vCont;c + vCont;s:1 vCont;s:1;s:2;s:3;s:3;s:4;...s:N;c == vCont;s:1;s:2;s:3 + vCont;s:4;...s:N;c etc. ) > > Or does the default only match any thread without an explicit match? > (which is how I interpreted the old spec) Maybe I should just remove all mentions of a "default" from the text? Like: ~~~ For each inferior thread, the leftmost action with a matching thread-id is applied. Threads that don’t match any action remain in their current state. Thread IDs are specified using the syntax described in thread-id syntax. If multiprocess extensions (see multiprocess extensions) are supported, actions can be specified to match all threads in a process by using the ‘ppid.-1’ form of the thread-id. An action with no thread-id is called the default action and matches all threads. Specifying multiple default actions is an error; specifying no actions is also an error. ~~~ To this: ~~~ For each inferior thread, the leftmost action with a matching thread-id is applied. Threads that don’t match any action remain in their current state. Thread IDs are specified using the syntax described in thread-id syntax. If multiprocess extensions (see multiprocess extensions) are supported, actions can be specified to match all threads in a process by using the ‘ppid.-1’ form of the thread-id. An action with no thread-id matches all threads. Specifying no actions is an error. ~~~ Would that help ? Thanks, Pedro Alves diff --git c/gdb/doc/gdb.texinfo w/gdb/doc/gdb.texinfo index d636a16..df548dc 100644 --- c/gdb/doc/gdb.texinfo +++ w/gdb/doc/gdb.texinfo @@ -35538,9 +35538,8 @@ syntax described in @ref{thread-id syntax}. If multiprocess extensions (@pxref{multiprocess extensions}) are supported, actions can be specified to match all threads in a process by using the @samp{p@var{pid}.-1} form of the @var{thread-id}. An action with no -@var{thread-id} is called the default action and matches all threads. -Specifying multiple default actions is an error; specifying no actions -is also an error. +@var{thread-id} matches all threads. Specifying no actions is an +error. I.e., go from this: