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 ges dot redhat dot com>
- To: Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Fri, 16 Aug 2002 10:42:42 -0400
- Subject: Re: RFC: Two small remote protocol extensions
- References: <20020502022543.GA22594@nevyn.them.org> <20020816143040.GA22041@nevyn.them.org>
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