Re: RFC: Two small remote protocol extensions

[Andrew Cagney <ac131313@ges.redhat.com>]

> Inferior_ptid is set in this case.  That's the whole problem; they have
> access to it, but the remote implementation doesn't.  The code from
> lin-lwp:
> 
>   /* Apparently the interpretation of PID is dependent on STEP: If
>      STEP is non-zero, a specific PID means `step only this process
>      id'.  But if STEP is zero, then PID means `continue *all*
>      processes, but give the signal only to this one'.  */
>   resume_all = (PIDGET (ptid) == -1) || !step;
> 
>   if (resume_all)
>     iterate_over_lwps (resume_set_callback, NULL);
>   else
>     iterate_over_lwps (resume_clear_callback, NULL);
> 
>   /* If PID is -1, it's the current inferior that should be
>      handled specially.  */
>   if (PIDGET (ptid) == -1)
>     ptid = inferior_ptid;
> 
> (I'm not quite sure about that comment; that might want to be revisited
> later... there should be a way to continue just one process.  I thought
> I remembered that working, but I must have been mistaken.)

Hmm,

I'm more interested in Solaris (since that target has a thread model 
which allows control of the entire thread group).  With that one, I 
couldn't find an equivalent operation (I've probably missed it.).

It's just really wierd (wrong?) that one layer of GDB thinks that it 
only needs to specify the step thread when doing the thread hop, yet the 
next layer down finds it necessary to always specify the step thread :-?

Andrew