This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: RFC: Two small remote protocol extensions
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Thu, 02 May 2002 11:38:02 -0400
- Subject: Re: RFC: Two small remote protocol extensions
- References: <20020502022543.GA22594@nevyn.them.org>
> 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.
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