Re: RFC: Two small remote protocol extensions

Daniel Jacobowitz
2002-08-16T14:52:43Z

On Fri, Aug 16, 2002 at 10:42:42AM -0400, Andrew Cagney wrote:
> >On Wed, May 01, 2002 at 10:25:43PM -0400, Daniel Jacobowitz wrote:
> >
> >>In making remote thread debugging work on GNU/Linux, I needed two
> >>additions
> >>to the remote protocol. Neither is strictly necessary, but both are
> >>useful,
> >>IMHO.
> >>
> >>They are:
> >>
> >> - two new replies to the continue/step packets, 'n' and 'x'. They
> >>indicate thread creation and death respectively, and are asynchronous;
> >>the target is not stopped when they are sent.
> >
> >
> >This one got shouted down, I'm not going to bring it up again.
> >
> >
> >> - A new 'Hs' packet, paralleling Hc and Hg. This sets the "step"
> >> thread.
>
> How is ``Hs'' different to:
>
> Hc<PID>
> s

Hc<PID> has a definite meaning right now. It means, step ONLY this
thread. That corresponds to set scheduler-locking (on|step). Hc0 will
be sent if we are not using scheduler locking.

I see nothing wrong with the current meaning of Hc.

Also, Hs was never meant to INCLUDE the step command. It sets a thread
context, that's all.

> >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.
>
> Shouldn't it pick the current-thread.

As above.

> >We need to either:
> > - Communicate inferior_ptid via Hg at this time
> > - Communicate inferior_ptid via a new Hs explicitly
> >
> >I think the former makes sense. Here's a patch; what do you think of
> >it? Also included is the patch for gdbserver; I'd send a separate
> >patch along afterwards to remove the vestiges of Hs from my testing,
> >which escaped in the original threads patch.
>
> No. general thread is really ``selected thread'' the thread for which
> the [gG][pP] packets apply. It is not involved in thread scheduling.

We need two thread markers to step correctly; I think using this one is
more logical. If you prefer then the code in gdbserver to use Hs is
already there.

> Separate to this is the user interface issue of, if you select a
> different thread, and then do a step, things get real confused (I think
> GDB tries to step the current (or stop) thread).

No, actually, gdbserver is what gets confused. You've said this
several times, and the last time you said it I went to check. In all
my tests, both local (lin-lwp) and remote (with Hs patch), everything
stepped the selected thread gracefully. This already works. Even
scheduler locking works.

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer