This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: RFC: Two small remote protocol extensions
- From: Andrew Cagney <ac131313 at redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 03 Sep 2003 19:41:28 -0400
- 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>
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