From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16592 invoked by alias); 30 Sep 2003 14:51:04 -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 16584 invoked from network); 30 Sep 2003 14:51:03 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 30 Sep 2003 14:51:03 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A4LqB-0006pe-C2; Tue, 30 Sep 2003 10:51:03 -0400 Date: Tue, 30 Sep 2003 14:51: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: <20030930145103.GA26117@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb-patches@sources.redhat.com References: <20030929152911.GA23320@nevyn.them.org> <3F78A178.5000302@redhat.com> <20030929212507.GA12032@nevyn.them.org> <3F799541.4070009@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F799541.4070009@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-09/txt/msg00653.txt.bz2 On Tue, Sep 30, 2003 at 10:37:53AM -0400, Andrew Cagney wrote: > >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. > > I agree that ":" _feels_ more natural, it just goes against the rest of > the packet where ";", and not ":" is the separator. It lets the packet > be specified as: > > packet ->> "vCont" { field }+ > field ->> ";" action [ ":" tid ] > > which is very easy to parse. BTW, intro has this to say, so there > aren't any guidelines :-( That loses the requirement that the default action be last, which I'd like to hold on to - OK? I dislike the ';' because vCont is not an item in the list of actions that the semicolons are separating; that turns ';' from a separator into a prefix. But hey, prefixes are people too. > >Fields within the packet should be separated using @samp{,} @samp{;} or > >@cindex remote protocol, field separator > >@samp{:}. Except where otherwise noted all numbers are represented in > >@sc{hex} with leading zeros suppressed. > > > >Implementors should note that prior to @value{GDBN} 5.0, the character > >@samp{:} could not appear as the third character in a packet (as it > >would potentially conflict with the @var{sequence-id}). > > > > >>>+@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. > > Suggest a table. OK. > >>>+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? > > It runs completly against the remote protocol's RPC model: one request, > one response. > > The transaction contains extra states, while those states add to the > transactions complexity, they do it without adding any real value: > > It adds unnecessary latency (due to additional round trips) to the > transaction. Remember this really involves: > -> vCont;.... > <- + > <- OK > -> + > <- T00.... > -> + > when just: > -> vCont;... > <- + > <- T00 > -> + > is all that is needed. > > When async, having fewer states makes the state machine logic easier. All right. I now remember having this conversation before; witness the other half of the original thread, with new-thread notifications. I don't really see the problem but I'm fine simplifying it. > >>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. > > What does: > > vCont; > > return then then? I think "T00" would make sense - target stopped, > nothing interesting happened. The other would be "E..". I'd prefer E..; vCont; resumes nothing, and generates no new stops. > Here's something out of left field: > > -> vCont? > <- { "s" | "c" | "P" | "E" | ... } OR "" > > that is, it returns a list of supported letters. Ooh, I like it, I like it. Allow both ? and ; as terminators, require any stub which implements vCont; to also implement vCont?, and there goes the probing problem. Then the rest of it falls out. Let me polish that up and test it and I'll send out an update. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer