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, 17 Sep 2003 12:19:35 -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> <20030917155115.GA7896@nevyn.them.org>
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:
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.