This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: RFC: Two small remote protocol extensions
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