From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22863 invoked by alias); 29 Sep 2003 21:25:15 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22851 invoked from network); 29 Sep 2003 21:25:11 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 29 Sep 2003 21:25:11 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A45W0-0003A5-3m; Mon, 29 Sep 2003 17:25:08 -0400 Date: Mon, 29 Sep 2003 21:25:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: RFA/RFC: vCont for the remote protocol [doco] Message-ID: <20030929212507.GA12032@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20030929152911.GA23320@nevyn.them.org> <3F78A178.5000302@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F78A178.5000302@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-09/txt/msg00643.txt.bz2 On Mon, Sep 29, 2003 at 05:17:44PM -0400, Andrew Cagney wrote: > >-@item @code{v} --- reserved > >+@item @code{v} --- verbose packet prefix > > > >-Reserved for future use. > >+Packets starting with @code{v} are identified by a multi-letter name, > >+up to the first @code{:} if any. > > ... first non-alpabetic character, if any. Unless you want to pin down > the terminator? > > I think ";" will work better as, in the below, it better separates out > the separate actions. I meant to pin down the terminator. If you want a ';' then that's OK by me, I can update the patch to use a semicolon. Makes sense, but the colon felt more natural. > >+@item > >@code{vCont:}[@var{action}@code{:}@var{tid}@code{;}]...[@var{action}] --- > >extended resume > >+@cindex @code{vCont} packet > >+ > >+Resume the inferior. Different actions may be specified for each thread. > >+If a final action is specified, then it is applied to all threads not > >+explicitly mentioned; if no final action is specified, all other threads > >+should remain stopped. Possible actions are @code{s}, @code{S}@var{sig}, > >+@code{c}, and @code{C}@var{sig}, with the same meanings as those packets. > >+The final @var{addr} associated with those packets is not supported in > >+@code{vCont}. Thread IDs are specified in hexadecimal. > >+ > >+First reply: > >+@table @samp > >+@item OK > > No. > > The behavior shall be identical to the other continuation packets. If > it isn't recognized, "" is returned. I did this in parallel to 'E'. Yes, I realize that 'E' has problems, but I really think this isn't one of them; it keeps the client code a whole lot simpler, since we don't have to detect and handle a failed vcont in the main loop. We can fall back immediately to sending a 'c' packet or whatever. It also lets us retry using 'C' for free. Also, the ability to differentiate between "stub does not support vcont" and "this vcont was illegal" seems useful to me - for debugging purposes if nothing else. Or if some stub supports step-out-of-range in a vcont packet (I think that would be a bad idea; call it vCont2 instead and avoid the issue). Why do you prefer not doing this? > You may find it useful to clarify the spec so that a separate probe is > possible vis > > -> vCont > <- Enn or OK or Tnn? > > || -> vCont > <- > > speaking of which. What happens if vCont specifies nothing? Return a > dummy Tnn packet? Return OK? Implementation currently returns ""; it only recognizes vCont with the colon. > > >+for success > >+@item E@var{NN} > >+for an error > >+@end table > >+ > >+If the first reply is @samp{OK}, then the inferior will be resumed, and > >+another reply sent when it stops. @xref{Stop Reply Packets}, for the > >reply > >+specifications. > > Andrew > > > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer