Re: RFC: Two small remote protocol extensions

[Quality Quorum <qqi at theworld dot com>]

On Thu, 2 May 2002, 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).
>
> >   - 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.

There some more annoying things in gdb protocol which require careful
consideration:

1. zbreaks support by kind - how gdb can dynamically learn that particular
   kind of zbreak is not supported by target

2. zbreaks support by count - how gdb can dynamically learn that
   it is trying to set one zbreak too many.

3. reconnect - how target could learn that it got a connect from
   a new session so it has to forget about all zbreaks.

4. exact meaning of Hg - last time I checked it was related to registers

5. exact meaning of Hc - last time I check it did not mean anything
   because gdb itself was not able to support per thread breakpoints

6. gdb should be able to switch dynamically to soft-stepping if
   target does not support steps

7. Have configurable option to remove breakpoints before doing steps

8. Obsolete 'is-thread-alive'.


Can somebody write a draft spec so we can discuss it as  a whole,
naturally, if you want you can start from one written by me but it
is completely unnesessary - just clean-up the thing to truly usable
state.

> Andrew

Thanks,

Aleksey

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