From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 756 invoked by alias); 3 Sep 2003 23:41:31 -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 740 invoked from network); 3 Sep 2003 23:41:30 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 3 Sep 2003 23:41:30 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id AA84E2B7F; Wed, 3 Sep 2003 19:41:28 -0400 (EDT) Message-ID: <3F567C28.1040906@redhat.com> Date: Wed, 03 Sep 2003 23:41: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: <20020816143040.GA22041@nevyn.them.org> <3D5D0F62.4010207@ges.redhat.com> <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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00047.txt.bz2 > 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? Andrew