From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14788 invoked by alias); 17 Sep 2003 15:51:17 -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 14745 invoked from network); 17 Sep 2003 15:51:15 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 17 Sep 2003 15:51:15 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 19zeaJ-0002Bs-6s; Wed, 17 Sep 2003 11:51:15 -0400 Date: Wed, 17 Sep 2003 15:51:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions Message-ID: <20030917155115.GA7896@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <20020816145306.GA24002@nevyn.them.org> <3D65B53D.8050603@ges.redhat.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3F567C28.1040906@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-09/txt/msg00210.txt.bz2 On Wed, Sep 03, 2003 at 07:41:28PM -0400, Andrew Cagney wrote: > > >et cetera? > > > >Maybe allow: > > HtTID,TID,TIDs;0c > > I don't think this case can arise. Well at least not immediatly. A > `hey we're thinking in this direction' comment wouldn't hurt though. > > >[Is 0 a valid TID?] > > GDB doesn't think it is (which can give targets grief :-/). However, it > could be a [sc] without the "0". > > >Could we deprecate Hg/Hc in favor of this, to avoid specifying all the > >interactions? > > > >And is there any hope of fixing this in 6.0? :((( > > Maybe 6.0.1. > > Hmm, why are we even fighting with the H packet? The senario is GDB > telling the target to resume in more weird and more wonderful ways. > > - single step a thread > - continue a thread > - step out of range a thread > - signal a thread > - continue or freeze remaining threads > > can GDB simply grab a new letter and spec out it's real intent? 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. 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. 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). Ht 'TID' 'DISPOSITION' [';' 'TID' 'DISPOSITION']... [';' 'DISPOSITION'] 'TID' should be a numeric thread ID, to affect one thread. 'DISPOSITION' can be: 's' 'c' 'C' 'SIGNAL' 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer