Re: RFC: Two small remote protocol extensions

[Andrew Cagney <ac131313 at ges dot redhat dot com>]

> 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