This is the mail archive of the
mailing list for the GDB project.
Re: RFC: Two small remote protocol extensions
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Wed, 17 Sep 2003 11:51:15 -0400
- Subject: Re: RFC: Two small remote protocol extensions
- References: <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> <3F567C28.email@example.com>
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
> >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:
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.
MontaVista Software Debian GNU/Linux Developer