Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz <drow at mvista dot com>]

On Thu, May 02, 2002 at 11:38:02AM -0400, Andrew Cagney 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.
> 
> No.
> 
> Telling GDB of thread create/delete events is a good idea, but please, 
> do it synchronously (we've already got the ``O'' packet and that is bad 
> enough).
> 
> Have you tried:
> 	T00Thread....?
> for the create event.  (signal 0 is loosely defined as a non-event).

That defeats the point of a fast thread debugging package.  I do not
want to stop threads at creation/death events; I put in quite a lot of
work to avoid it.  That scales very badly.  The alternative was to just
report all thread events at the next stop, but it is much more
user-intuitive to do it immediately.

Could you please explain why you are opposed to asynchronous
notification?  The 'O' packet doesn't seem to be "bad enough";
doing output notification synchronously just seems silly.

(Note that they're still ack'd, like standard remote packets.  It's
just that the target isn't stopped.)

> >  - A new 'Hs' packet, paralleling Hc and Hg.  This sets the "step" thread.
> 
> I don't know.
> 
> What is the difference between Hc and Hs?  BTW, Hg is orthogonal to the 
> step/continue problem.  Anyway, I suspect Michael knows more than most 
> on this front and this needs very careful consideration.

When you step without scheduler locking, the normal GDB behavior is to
step one thread and continue (then stop) all the others.  Hc0 is sent
beforehand to indicate that all threads should be continued.  Which
thread should be stepped?

We can indicate this via Hg, since it has no meaning at that point; or
we can indicate it via a new Hs.  I don't care ;)


> 
> Andrew
> 
> >Basically, despite a comment that it didn't work earlier on this list, I
> >discovered that lin-lwp does correctly honor `set scheduler-locking'.  It
> >works by controlling which threads are resumed by resume_ptid.  However,
> >for stepping, inferior_ptid is also consulted.  That way all threads can
> >be resumed but a particular thread stepped.  The `thread <N>' command
> >changes the thread to be stepped.
> >
> >resume_ptid is communicated to the remote host.  inferior_ptid is not
> >necessarily the same as general_ptid, however - after information requests
> >like `thread apply all bt', for instance.
> 
> Yes.  Hg has nothing to do with Hc.
> 
> >Reading over the above, I suppose I could use general_ptid for this 
> >instead,
> >with a slightly smaller patch to remote_resume to guarantee that it is set.
> >That makes a little more sense than my current approach.  Still needs a
> >documentation patch to clarify it; I intend to fix up most of the protocol
> >specification (which is woefully out of date, and hideous in texinfo) as
> >soon as I get a chance.
> >
> >Any thoughts on the two above changes?
> >
> >-- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian 
> >GNU/Linux Developer 
> 
> 
> 

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer