From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 304 invoked by alias); 17 Sep 2003 16:19:38 -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 32744 invoked from network); 17 Sep 2003 16:19:37 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 17 Sep 2003 16:19:37 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8A7392B89; Wed, 17 Sep 2003 12:19:35 -0400 (EDT) Message-ID: <3F688997.4030605@redhat.com> Date: Wed, 17 Sep 2003 16:19: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@sources.redhat.com Subject: Re: RFC: Two small remote protocol extensions 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> <20030917155115.GA7896@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00212.txt.bz2 > 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 :-) > 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). > 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 :-) > 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. Andrew