This is the mail archive of the
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.firstname.lastname@example.org> <20020816145306.GA24002@nevyn.them.org> <3D65B53D.email@example.com> <20020823124453.GA12257@nevyn.them.org> <3D6692AE.firstname.lastname@example.org> <20020823201549.GB26809@nevyn.them.org> <3D6C4C4E.email@example.com> <20020828133445.GA16642@nevyn.them.org> <3D93B6E6.firstname.lastname@example.org> <20030629021605.GA18990@nevyn.them.org>
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
And is there any hope of fixing this in 6.0? :(((
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?