From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51114 invoked by alias); 2 Nov 2016 15:30:58 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 48105 invoked by uid 89); 2 Nov 2016 15:30:56 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=equivalents, coordination, H*MI:sk:94eb2c0 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 02 Nov 2016 15:30:52 +0000 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 ADF72C057EC9; Wed, 2 Nov 2016 15:30:51 +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 uA2FUoS6025950; Wed, 2 Nov 2016 11:30:50 -0400 Subject: Re: vCont: optional packet or not? To: Doug Evans , gdb@sourceware.org References: <94eb2c043598965907054043d1f7@google.com> From: Pedro Alves Message-ID: Date: Wed, 02 Nov 2016 15:30:00 -0000 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: <94eb2c043598965907054043d1f7@google.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-11/txt/msg00001.txt.bz2 On 11/01/2016 09:15 PM, Doug Evans wrote: > Hi. > > Two main questions/issues: > 1) In non-stop mode is vCont a required or optional packet > a stub needs to provide? I thought we already documented that it's required, but I could only find this comment in gdb/remote.c: ... only to the base all-stop protocol, however. In non-stop (which only supports vCont), the stub replies with an "OK", and is immediate able to process further serial input. */ if (!target_is_non_stop_p ()) rs->waiting_for_stop_reply = 1; All along I though it was mentioned in the docs somewhere. :-( Since only vCont is asynchronous (s/c/S/C are not), it seems useless to support non-stop without vCont ? We do still send the reverse variants of s/c in non-stop mode, since there are no vCont equivalents... So maybe we should instead say vCont is recommended instead of required? > 2) Trunk seems to have regressed (could be wrong) with respect > to first checking whether vCont is supported before using it. > In 7.12 it seems optional. I don't remember exactly, but > the 7.12 code does do some checking whether vCont is supported > before sending vCont packets. > > Things are further confusing :-( :-( :-( because > there's also vContSupported which the docs say indicates whether > vCont? is supported, not whether vCont is supported. > [The name could be a teensy bit better ...] > vCont? will tell gdb whether vCont is supported (including > what flavors (c,C,s,S,t,...), but gdb only uses this to check > whether vCont;[sS] (singlestepping) is supported, not whether e.g., > vCont;[cC] (continue) is supported. > > So where's the check for whether vCont;[cC] is supported? I agree it's confusing . > Things have changed from 7.12, I think, in trunk. > I'm seeing gdb issue vCont;c packets and complaining > about bad replies from my stub, but it has never asked > or even checked whether the packet is supported. > [e.g., remote_commit_resume just blindly sends vCont.] > > What's the story here? Right, I didn't add any check to see if vCont was supported in that code path, with the assumption that no non-stop stub would skip implementing vCont. The coordination between remote_resume and remote_commit_resume is done at the top of each of those functions: static void remote_resume (struct target_ops *ops, ptid_t ptid, int step, enum gdb_signal siggnal) { struct remote_state *rs = get_remote_state (); /* When connected in non-stop mode, the core resumes threads individually. Resuming remote threads directly in target_resume would thus result in sending one packet per thread. Instead, to minimize roundtrip latency, here we just store the resume request; the actual remote resumption will be done in target_commit_resume / remote_commit_resume, where we'll be able to do vCont action coalescing. */ if (target_is_non_stop_p () && execution_direction != EXEC_REVERSE) ... /* to_commit_resume implementation. */ static void remote_commit_resume (struct target_ops *ops) { struct remote_state *rs = get_remote_state (); struct inferior *inf; struct thread_info *tp; int any_process_wildcard; int may_global_wildcard_vcont; struct vcont_builder vcont_builder; /* If connected in all-stop mode, we'd send the remote resume request directly from remote_resume. Likewise if reverse-debugging, as there are no defined vCont actions for reverse execution. */ if (!target_is_non_stop_p () || execution_direction == EXEC_REVERSE) return; ... It should be doable to include a "vCont is supported" check here. Not sure it's worth it though. > If someone can describe how things are intended to work, > I'll volunteer to fix/enhance the remote protocol spec > in the docs. [Or you can directly.] Thanks, Pedro Alves