RFC: Two small remote protocol extensions

[Andrew Cagney]

> 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:
>   's'
>   'c'
>   'C' 'SIGNAL'

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.

Yep.

Andrew