RFC: Two small remote protocol extensions

Andrew Cagney ac131313@ges.redhat.com
Fri Aug 16 07:42:00 GMT 2002


> 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

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

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

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

Andrew




More information about the Gdb mailing list