RFC: Two small remote protocol extensions

[Andrew Cagney]

> This one, however, needs feedback.  A user just reported a bogus
>> >SIGTRAP bug to me which is fixed by the above.
>> >
>> >To elaborate on the problem: right now we have two ways of specifying a
>> >thread to the remote agent.  Hg specifies the "general" thread, and Hc
>> >specifies the "continue" thread.  These correspond to inferior_ptid and
>> >resume_ptid, roughly.
>> >
>> >When we single-step, if we are not using some form of
>> >scheduler-locking, resume_ptid is 0.  We don't tell the agent at that
>> >point what inferior_ptid is; it has to step _some_ thread, and it picks
>> >one, and if it doesn't pick the one GDB expected we get problems.

I think it is passed down when schedule locking and when doing a thread hop.

I'm wondering how native thread implementations handle your case?  I 
don't see how remote_resume(), or any of the other resume functions can 
know which thread to step since the only parameter available to them is 
resume-ptid and you're indicating that that is NULL.

Andrew