Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Aug 23, 2002 at 12:08:29AM -0400, Andrew Cagney wrote:
> 
> >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 don't believe so, but I'm not sure what you mean exactly.

> 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.

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.)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer