From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26845 invoked by alias); 22 Sep 2003 01:01:24 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26838 invoked from network); 22 Sep 2003 01:01:23 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 22 Sep 2003 01:01:23 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 1A1F4t-0001Tl-B1; Sun, 21 Sep 2003 21:01:23 -0400 Date: Mon, 22 Sep 2003 01:01:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions Message-ID: <20030922010122.GA5600@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <20020823201549.GB26809@nevyn.them.org> <3D6C4C4E.4050409@ges.redhat.com> <20020828133445.GA16642@nevyn.them.org> <3D93B6E6.8030805@redhat.com> <20030629021605.GA18990@nevyn.them.org> <3F567C28.1040906@redhat.com> <20030917155115.GA7896@nevyn.them.org> <3F688997.4030605@redhat.com> <20030917162321.GA25144@nevyn.them.org> <3F6E41F4.2090603@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F6E41F4.2090603@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-09/txt/msg00260.txt.bz2 On Sun, Sep 21, 2003 at 08:27:32PM -0400, Andrew Cagney wrote: > > >OK. I think there's room to add it to something like this, so I'm not > >gonna fret about it for now. > > > > > >>> Ht 'TID' 'DISPOSITION' [';' 'TID' 'DISPOSITION']... [';' 'DISPOSITION'] > >>> > >>>'TID' should be a numeric thread ID, to affect one thread. > >>> > >>>'DISPOSITION' can be: > >>> 's' > >>> 'c' > >>> 'C' 'SIGNAL' > > > >> > >>I hope TID is decimal :-) > > Hmm, I think it should be more LL1, which the above (and the remote > protocol :-) isn't. Something like: > > c:TID > s:TID > C:SIG:TID > > that way someone can later add: > > p:REG:VALUE What would that mean, anyway? Since there's no clear thread we're talking about... it could be p:TID:REG:VALUE but I don't see the use :) > Oh and TID is hex: > > if (strncmp (p, "thread", p1 - p) == 0) > { > p_temp = unpack_varlen_hex (++p1, &thread_num); > > > by @code{REGISTER_RAW_SIZE}; @var{n...} = @samp{thread}, @var{r...} = > > thread process ID, this is a hex integer; @var{n...} = (@samp{watch} | > > :-( :( > >Heh, 'c', right. Any objection to using decimal thread IDs, or would > >you rather have 'TID' : 'DISPOSITION' ; ... ? > > > > > >>>A final 'DISPOSITION' is applied to all threads not explicitly listed. > >>> > >>>Note that this Ht is a continue packet, not a select-thread packet. So > >>>Ht is not a good choice. > > > >> > >>Yep. > > > > > >How about, um, "vCont"? > > As in: > > vCont;s:456;C04:aba;c > > or "n" for "next" > > [n]ext;s:456;C04:aba;c > > Main thing is that, the entire leading word must be matched. > > The choice, I think, is: a, e, E, f, h, j, J, K, l, L, n, N, o, O, u, U, > v, V, w, x, y, Y. > > (I should mark [eE] has do-not-use). Right, something like that. As above I guess it would be C:04 instead of CO4. I didn't want to take x because of the logical parallel to X. How about picking a prefix for all new "long" commands? I was going to use v for "verbose". I'll give this a whirl this week. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer