Re: RFC: Two small remote protocol extensions

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

Lets get rid of the easy one (...) `Hg':

``

@item @code{Hg}@var{id} --- set general thread
@cindex @code{Hc} packet

Select the general thread.  Register and memory read and write 
operations apply to the most recently selected general thread. 
@var{id}, a hex encoded cardinal, is the identifier of the selected thread.

After a target stop, the general thread is reset to the thread 
identifier of the stopped thread.

@emph{Implementation note:  The @code{Hg} packet can not be used to 
determine the most recently selected thread (using the @samp{thread 
@var{thread-id} command).  This is because @value{GDBN} can cache 
per-thread data and avoid the need to re-query the target on each 
@samp{thread} command.}

@c Note the word ``can'' is used, not ``does'' :-)

Reply:
@table @samp
@item OK
for success
@item E00
unspecified error
@c ESRCH --- no such proces/thread?
@item @samp{}
unsupported
@end table

''

Andrew


> 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