From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4010 invoked by alias); 17 Sep 2003 16:23:22 -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 4003 invoked from network); 17 Sep 2003 16:23:21 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 17 Sep 2003 16:23:21 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 19zf5N-0000yB-5E; Wed, 17 Sep 2003 12:23:21 -0400 Date: Wed, 17 Sep 2003 16:23:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions Message-ID: <20030917162321.GA25144@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <20020823124453.GA12257@nevyn.them.org> <3D6692AE.90601@ges.redhat.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F688997.4030605@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-09/txt/msg00213.txt.bz2 On Wed, Sep 17, 2003 at 12:19:35PM -0400, Andrew Cagney wrote: > > >Well, Ht is effectively a new letter - H is only defined for c and g. > >We could explicitly state that, or look for a new letter. I recommend > >a multi-letter sequence, the extra bytes don't matter and we don't have > >all that many letters. > > Definitly a multi-letter sequence, but a new letter :-) > > >To summarize, here's what we seem to have now natively: > > - Single step one thread, all others stopped. > > - Single step one thread, all others continued. > > - Signal one thread, all others stopped. > > - Signal one thread, all others continued. > > - Continue all threads. > > > >Here's what I think would be useful, though: > > - Per thread, specify stopped/singlestepped/signal/continue. > > > >Some of the combinations aren't useful; singlestepping multiple threads > >for instance is not usually useful. Well, I suppose it could be. > > Who are we to argue :-) Heh. > >But specific signals to multiple threads at the same time (well, same > >time is really kind of approximate without better native interfaces...) > >- now that's useful in debugging race conditions. > > > >So, do you agree? If so, here's just one possible way to implement it. > >I left it as Ht because I'm too lazy to go find another letter. This > >doesn't include step out of range because I'm not sure how that should > >look (what was the problem with step out of range anyway? That caused > >it to get disabled? - and its current syntax is not in the manual). > > It wasn't thread friendly, wasn't documented, it wasn't consistent with > the other continuation packets (it had two replies). 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 :-) 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"? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer