From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10344 invoked by alias); 30 Sep 2003 14:37:55 -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 10265 invoked from network); 30 Sep 2003 14:37:53 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 30 Sep 2003 14:37:53 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 40FAB2B89; Tue, 30 Sep 2003 10:37:53 -0400 (EDT) Message-ID: <3F799541.4070009@redhat.com> Date: Tue, 30 Sep 2003 14:37:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: RFA/RFC: vCont for the remote protocol [doco] References: <20030929152911.GA23320@nevyn.them.org> <3F78A178.5000302@redhat.com> <20030929212507.GA12032@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00651.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. 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 :-( > 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. >> >+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. >> 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..". Here's something out of left field: -> vCont? <- { "s" | "c" | "P" | "E" | ... } OR "" that is, it returns a list of supported letters. Andrew