RFC: Two small remote protocol extensions

RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

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.

  - A new 'Hs' packet, paralleling Hc and Hg.  This sets the "step" thread.

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.

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

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> 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 

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

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

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

I'm fairly sure that the archives have plenty of info on the ``O'' 
packet and why/how it should be replaced.  One thread is ``gdb/remote - 
I/O''.

enjoy,
Andrew

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

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Thu, May 02, 2002 at 12:39:37PM -0400, Andrew Cagney wrote:
> I'm fairly sure that the archives have plenty of info on the ``O'' 
> packet and why/how it should be replaced.  One thread is ``gdb/remote - 
> I/O''.

Ah, I've found the thread.  I see that there was a rough consensus
(among just about everyone but J.T. Conklin, who I believe was remote
maintainer at the time?) about the disadvantages of asynchronous
replies.  However, I'd like to add another point of view.

These are threading information packets.  They are completely optional,
and I believe that they are of an appropriate nature for the
environments which support it; such systems generally:

  a) Should have no trouble implementing asynchronous responses.
	It needed about fifteen lines of code changed in gdbserver,
	so most Unix-alikes should be fine.  VxWorks could certainly
	do it as well.

  b) Desire the least-intrusive possible thread debugging.
	These aren't niche events; in a multithreaded application,
	thread creation and deletion can happen very frequently, and
	with a large number of running threads.  I've heard a lot
	of complaints about how much our intrusive thread debugging
	harasses scheduler priorities.

I'd rather ditch the notifications entirely than stop other threads;
I'll keep the notification code out of the FSF tree until we can figure
out a generally acceptable way to pass asynchronous status
notifications back to the client.  I really don't see the problem with
my suggestion, though.

Heck, if I can work out a way to do it safely, I intend to do
one-thread-stopped-only SVR4 shared library support also.  I've heard
that starting apache2 (multithreaded, and with all modules as DSOs)
takes several minutes instead of the second or two that it takes
without GDB attached.

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

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

Re: RFC: Two small remote protocol extensions

[Kevin Buettner]

On May 2,  3:14pm, Daniel Jacobowitz wrote:

> Heck, if I can work out a way to do it safely, I intend to do
> one-thread-stopped-only SVR4 shared library support also.

Can you explain what you mean by this?

Kevin

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Thu, May 02, 2002 at 12:22:35PM -0700, Kevin Buettner wrote:
> On May 2,  3:14pm, Daniel Jacobowitz wrote:
> 
> > Heck, if I can work out a way to do it safely, I intend to do
> > one-thread-stopped-only SVR4 shared library support also.
> 
> Can you explain what you mean by this?

I'd like to (where possible; probably not in every circumstance!)
update the shared library information without stopping all threads. At
least glibc's dynamic linker does enough locking on its own (so that
multiple threads calling dlopen() do not trample each other) that when
one thread has stopped it is safe to examine the link maps; I assume
that this is true for other systems which support both threads and
dlopen as well (e.g. Solaris).

As I said in the original message, starting Apache 2 in multithreaded
mode stops all threads every time a module is loaded; that's painful,
since I believe modules can be loaded after server threads have been
created (and on demand, per-request, in some cases).  The mod_perl
developers were complaining about the speed hit several months ago.

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

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> On Thu, May 02, 2002 at 12:39:37PM -0400, Andrew Cagney wrote:
> 
>> I'm fairly sure that the archives have plenty of info on the ``O'' 
>> packet and why/how it should be replaced.  One thread is ``gdb/remote - 
>> I/O''.
> 
> 
> Ah, I've found the thread.  I see that there was a rough consensus
> (among just about everyone but J.T. Conklin, who I believe was remote
> maintainer at the time?) about the disadvantages of asynchronous

Joint.  I think the consensus was that the advantages of a more robust 
mechanism (some will laugh at the very suggestion that the GDB protocol 
is even vaguely robust :-) outway the disadvantages of having the 
protocol synchronous.

> replies.  However, I'd like to add another point of view.

At one level I agree with you completly, unfortunatly the remote 
protocol, as it stands, just don't work that way :-(  The ``O'' packet 
while ``a good idea at the time'' (sarcasm) just doesn't cut it when it 
comes to providing something that is reliable.

> These are threading information packets.  They are completely optional,
> and I believe that they are of an appropriate nature for the
> environments which support it; such systems generally:

Optional or not, it needs to be reliable.  You need to be able to run a 
test cases 1000 times and have it pass 1000 times.

>   a) Should have no trouble implementing asynchronous responses.
> 	It needed about fifteen lines of code changed in gdbserver,
> 	so most Unix-alikes should be fine.  VxWorks could certainly
> 	do it as well.
> 
>   b) Desire the least-intrusive possible thread debugging.
> 	These aren't niche events; in a multithreaded application,
> 	thread creation and deletion can happen very frequently, and
> 	with a large number of running threads.  I've heard a lot
> 	of complaints about how much our intrusive thread debugging
> 	harasses scheduler priorities.
> 
> I'd rather ditch the notifications entirely than stop other threads;
> I'll keep the notification code out of the FSF tree until we can figure
> out a generally acceptable way to pass asynchronous status
> notifications back to the client.  I really don't see the problem with
> my suggestion, though.

Hmm, I think you're trying to combine several disjoint features into a 
single mechanism.

Feature #1 is notify GDB of [remote] thread create/delete events.
Feature #2 is allow some [remote] threads to continue running while 
others (just current?) have stopped.

> Heck, if I can work out a way to do it safely, I intend to do
> one-thread-stopped-only SVR4 shared library support also.  I've heard
> that starting apache2 (multithreaded, and with all modules as DSOs)
> takes several minutes instead of the second or two that it takes
> without GDB attached.

Yes, feature #2 above.

enjoy,
Andrew

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Thu, May 02, 2002 at 04:13:31PM -0400, Andrew Cagney wrote:
> >These are threading information packets.  They are completely optional,
> >and I believe that they are of an appropriate nature for the
> >environments which support it; such systems generally:
> 
> Optional or not, it needs to be reliable.  You need to be able to run a 
> test cases 1000 times and have it pass 1000 times.

I really do not see what is unreliable here.  They're still ACKed...

> >  a) Should have no trouble implementing asynchronous responses.
> >	It needed about fifteen lines of code changed in gdbserver,
> >	so most Unix-alikes should be fine.  VxWorks could certainly
> >	do it as well.
> >
> >  b) Desire the least-intrusive possible thread debugging.
> >	These aren't niche events; in a multithreaded application,
> >	thread creation and deletion can happen very frequently, and
> >	with a large number of running threads.  I've heard a lot
> >	of complaints about how much our intrusive thread debugging
> >	harasses scheduler priorities.
> >
> >I'd rather ditch the notifications entirely than stop other threads;
> >I'll keep the notification code out of the FSF tree until we can figure
> >out a generally acceptable way to pass asynchronous status
> >notifications back to the client.  I really don't see the problem with
> >my suggestion, though.
> 
> Hmm, I think you're trying to combine several disjoint features into a 
> single mechanism.
> 
> Feature #1 is notify GDB of [remote] thread create/delete events.
> Feature #2 is allow some [remote] threads to continue running while 
> others (just current?) have stopped.
> 
> >Heck, if I can work out a way to do it safely, I intend to do
> >one-thread-stopped-only SVR4 shared library support also.  I've heard
> >that starting apache2 (multithreaded, and with all modules as DSOs)
> >takes several minutes instead of the second or two that it takes
> >without GDB attached.
> 
> Yes, feature #2 above.

I don't know how generally useful feature #2 is (although it's
certainly useful internally).  The question becomes whether core
GDB needs to know that some threads are still running, or if we can
get by without that.  Informing core GDB of this fact is beyond me.

I'd appreciate any comments on the Hs issue; I'm just going to leave
the notification packets out of the first submission of this code,
since they are controversial.

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

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> On Thu, May 02, 2002 at 04:13:31PM -0400, Andrew Cagney wrote:
> 
>> >These are threading information packets.  They are completely optional,
>> >and I believe that they are of an appropriate nature for the
>> >environments which support it; such systems generally:
> 
>> 
>> Optional or not, it needs to be reliable.  You need to be able to run a 
>> test cases 1000 times and have it pass 1000 times.
> 
> 
> I really do not see what is unreliable here.  They're still ACKed...

Not necessarily.

What should happen if, at the same time as the target is creating / 
sending an O packet, GDB sends a <BREAK>?  The protocol spec says nothing.

I believe, to define this, one would end up specifying a new protocol.

In the mean time, the existing protocol remains ``synchronous''.  GDB 
sends a request, the target replies.  At any time either GDB, xor the 
target is in control.

--

Out of interest, does the n/x packet code in gdbserver, let go of a 
created thread immediatly or does it wait until it has received the ack?

Andrew

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Fri, May 03, 2002 at 02:24:44PM -0400, Andrew Cagney wrote:
> >On Thu, May 02, 2002 at 04:13:31PM -0400, Andrew Cagney wrote:
> >
> >>>These are threading information packets.  They are completely optional,
> >>>and I believe that they are of an appropriate nature for the
> >>>environments which support it; such systems generally:
> >
> >>
> >>Optional or not, it needs to be reliable.  You need to be able to run a 
> >>test cases 1000 times and have it pass 1000 times.
> >
> >
> >I really do not see what is unreliable here.  They're still ACKed...
> 
> Not necessarily.
> 
> What should happen if, at the same time as the target is creating / 
> sending an O packet, GDB sends a <BREAK>?  The protocol spec says nothing.
> 
> I believe, to define this, one would end up specifying a new protocol.

I see; the only reason this is not an issue for 'T' responses is that
the break should be ignored in that case.  I actually handle this
correctly for TCP, if I get an interrupt while I'm expecting an ACK.

I don't know how this works on serial lines.  The <BREAK> clobbers the
traffic in the other direction?

> In the mean time, the existing protocol remains ``synchronous''.  GDB 
> sends a request, the target replies.  At any time either GDB, xor the 
> target is in control.

.. sort of; see above in that GDB is already in getpkt () when these
n/x packets are received.  So it thinks the target is in control. 
Asynchronous breaks are a separate problem.

> Out of interest, does the n/x packet code in gdbserver, let go of a 
> created thread immediatly or does it wait until it has received the ack?

Right now, waits for the ACK; it was easier and I'm more concerned
about running threads than new threads.  It would be more correct to
release the thread first, in my opinion, but that conflicts with
reporting "some threads stopped" to GDB.  Depends which direction we
go...

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

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> 
> I see; the only reason this is not an issue for 'T' responses is that
> the break should be ignored in that case.

The consequences of ignoring the break are harmless.

 > I actually handle this
> correctly for TCP, if I get an interrupt while I'm expecting an ACK.

Careful.  The behavour is undefined so there is nothing saying that your 
implementation is correct.

> I don't know how this works on serial lines.  The <BREAK> clobbers the
> traffic in the other direction?

Often a cntrl-c is sent instead of break.  GDB can also NACK partial 
packets.  If you go through enough cases you find gdb can lock up (until 
a timeout).

> Right now, waits for the ACK; it was easier and I'm more concerned
> about running threads than new threads.  It would be more correct to
> release the thread first, in my opinion, but that conflicts with
> reporting "some threads stopped" to GDB.  Depends which direction we
> go...

If you're holding onto the thread you're effectively synchronous.  The 
exchanges:

	<- n<new-thread>
	-> +

and

	<- T00<new-thread>
	-> +$C#..
	<- +

are, only marginally different.

Should all threads be halted during this exchange?  I think that is a 
separate question.

enjoy,
Andrew

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Fri, May 03, 2002 at 06:18:51PM -0400, Andrew Cagney wrote:
> If you're holding onto the thread you're effectively synchronous.  The 
> exchanges:
> 
> 	<- n<new-thread>
> 	-> +
> 
> and
> 
> 	<- T00<new-thread>
> 	-> +$C#..
> 	<- +
> 
> are, only marginally different.
> 
> Should all threads be halted during this exchange?  I think that is a 
> separate question.

I wouldn't call it effectively synchronous - precisely because no other
thread is stopped.  All threads shouldn't be halted, IMO, but I have
no way to tell GDB which are and which are not.

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

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> are, only marginally different.
>> 
>> Should all threads be halted during this exchange?  I think that is a 
>> separate question.
> 
> 
> I wouldn't call it effectively synchronous - precisely because no other
> thread is stopped.  All threads shouldn't be halted, IMO, but I have
> no way to tell GDB which are and which are not.

No/yes?  The protocol is effectivly synchronous in both cases.

Separate to this, GDB could be modified to not assume all threads 
stopped when a new thread is created.  This change can equally be 
implemented for a local/native and/or a remote target - something 
separate from the remote protocol.

enjoy,
Andrew

Re: RFC: Two small remote protocol extensions

[Quality Quorum]

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

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Thu, May 02, 2002 at 04:13:20PM -0400, Quality Quorum wrote:
> There some more annoying things in gdb protocol which require careful
> consideration:

I know.  I intend to clean up the spec documentation in a couple of
weeks, if I have time.

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

Yes, although it's unclear; for instance Txxxx;thread:N changes
general_thread.

> 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

It's used for scheduler locking.  GDB does support per thread
breakpoints (somewhat), but that's not related to Hc...


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

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

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

gdb/367

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

related to gdb/368

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

There is a biger bug here.

If the connection is tcp, then the target knows this because the tcp 
connection will have been re-built.

If the connection is serial, however, there is nothing to start / finish 
a session.

created gdb/523

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

It is similar to current frame VS selected frame.

When the target stops, there is single identifyable ``current thread'' 
that is considered responsible for the stop.

The user can then select another thread for examination.  This changes 
the ``selected thread'' but does not affect the ``current thread''.  A 
Hg packet is sent to the target to notify it that a new thread has been 
selected and that this new thread's registers should be operated on by 
the [Gg] and [pP] register packets.

Changing ``selected thread'' does not affect things like the scheduler.

created gdb/524

> 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

I believe it is used for a ``thread hop''.  A thread hop occures when 
you want to step just one thread over a breakpoint (without allowing any 
other threads to sneak through).

It doesn't have anything to do with per-thread breakpoints.

created gdb/525(?)

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

gdb/274

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

First thing to do, I think, is to rip out the @multitables in the 
current doco.

Andrew

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

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.

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.

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

2002-08-16  Daniel Jacobowitz  <drow@mvista.com>

	* remote.c (remote_resume): Also send inferior_ptid.

2002-08-16  Daniel Jacobowitz  <drow@mvista.com>

	* target.c (set_desired_inferior): Respect general_thread
	if cont_thread is 0 or -1.

Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.91
diff -u -p -r1.91 remote.c
--- remote.c	9 Aug 2002 16:41:24 -0000	1.91
+++ remote.c	16 Aug 2002 14:26:51 -0000
@@ -2616,8 +2616,13 @@ remote_resume (ptid_t ptid, int step, en
 {
   struct remote_state *rs = get_remote_state ();
   char *buf = alloca (rs->remote_packet_size);
-  int pid = PIDGET (ptid);
+  int pid = PIDGET (ptid), inf_pid = PIDGET (inferior_ptid);
   char *p;
+
+  if (inf_pid == -1)
+    set_thread (0, 1);
+  else
+    set_thread (inf_pid, 1);
 
   if (pid == -1)
     set_thread (0, 0);		/* run any thread */
Index: gdbserver/target.c
===================================================================
RCS file: /cvs/src/src/gdb/gdbserver/target.c,v
retrieving revision 1.3
diff -u -p -r1.3 target.c
--- gdbserver/target.c	11 Jun 2002 17:32:40 -0000	1.3
+++ gdbserver/target.c	16 Aug 2002 14:26:51 -0000
@@ -46,6 +46,10 @@ set_desired_inferior (int use_general)
 	found = (struct thread_info *) find_inferior_id (&all_threads,
 							 step_thread);
 
+      if (general_thread > 0 && (cont_thread == 0 || cont_thread == -1))
+	found = (struct thread_info *) find_inferior_id (&all_threads,
+							 general_thread);
+
       if (found == NULL)
 	found = (struct thread_info *) find_inferior_id (&all_threads,
 							 cont_thread);

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> 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

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Fri, Aug 16, 2002 at 10:42:42AM -0400, Andrew Cagney wrote:
> >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

Hc<PID> has a definite meaning right now.  It means, step ONLY this
thread.  That corresponds to set scheduler-locking (on|step).  Hc0 will
be sent if we are not using scheduler locking.

I see nothing wrong with the current meaning of Hc.

Also, Hs was never meant to INCLUDE the step command.  It sets a thread
context, that's all.

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

As above.

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

We need two thread markers to step correctly; I think using this one is
more logical.  If you prefer then the code in gdbserver to use Hs is
already there.

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

No, actually, gdbserver is what gets confused.  You've said this
several times, and the last time you said it I went to check.  In all
my tests, both local (lin-lwp) and remote (with Hs patch), everything
stepped the selected thread gracefully.  This already works.  Even
scheduler locking works.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

Ulgh, sorry.  I'll go and check my notes :-/

Andrew

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

Lets get rid of the easy one (...) `Hg':

``

@item @code{Hg}@var{id} --- set general thread
@cindex @code{Hc} packet

Select the general thread.  Register and memory read and write 
operations apply to the most recently selected general thread. 
@var{id}, a hex encoded cardinal, is the identifier of the selected thread.

After a target stop, the general thread is reset to the thread 
identifier of the stopped thread.

@emph{Implementation note:  The @code{Hg} packet can not be used to 
determine the most recently selected thread (using the @samp{thread 
@var{thread-id} command).  This is because @value{GDBN} can cache 
per-thread data and avoid the need to re-query the target on each 
@samp{thread} command.}

@c Note the word ``can'' is used, not ``does'' :-)

Reply:
@table @samp
@item OK
for success
@item E00
unspecified error
@c ESRCH --- no such proces/thread?
@item @samp{}
unsupported
@end table

''

Andrew


> On Fri, Aug 16, 2002 at 10:42:42AM -0400, Andrew Cagney wrote:
> 
>> >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
> 
> 
> Hc<PID> has a definite meaning right now.  It means, step ONLY this
> thread.  That corresponds to set scheduler-locking (on|step).  Hc0 will
> be sent if we are not using scheduler locking.
> 
> I see nothing wrong with the current meaning of Hc.
> 
> Also, Hs was never meant to INCLUDE the step command.  It sets a thread
> context, that's all.
> 
> 
>> >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.
> 
> 
> As above.
> 
> 
>> >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.
> 
> 
> We need two thread markers to step correctly; I think using this one is
> more logical.  If you prefer then the code in gdbserver to use Hs is
> already there.
> 
> 
>> 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).
> 
> 
> No, actually, gdbserver is what gets confused.  You've said this
> several times, and the last time you said it I went to check.  In all
> my tests, both local (lin-lwp) and remote (with Hs patch), everything
> stepped the selected thread gracefully.  This already works.  Even
> scheduler locking works.
> 
> -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer 

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Thu, Aug 22, 2002 at 10:23:15PM -0400, Andrew Cagney wrote:
> Lets get rid of the easy one (...) `Hg':
> 
> ``
> 
> @item @code{Hg}@var{id} --- set general thread
> @cindex @code{Hc} packet
> 
> Select the general thread.  Register and memory read and write 
> operations apply to the most recently selected general thread. 
> @var{id}, a hex encoded cardinal, is the identifier of the selected thread.
> 
> After a target stop, the general thread is reset to the thread 
> identifier of the stopped thread.
> 
> @emph{Implementation note:  The @code{Hg} packet can not be used to 
> determine the most recently selected thread (using the @samp{thread 
> @var{thread-id} command).  This is because @value{GDBN} can cache 
> per-thread data and avoid the need to re-query the target on each 
> @samp{thread} command.}
> 
> @c Note the word ``can'' is used, not ``does'' :-)
> 
> Reply:
> @table @samp
> @item OK
> for success
> @item E00
> unspecified error
> @c ESRCH --- no such proces/thread?
> @item @samp{}
> unsupported
> @end table
> 
> ''

Sure.  So, we need a way for it to know the current thread that doesn't
have that niggling little comment :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Two small remote protocol extensions

[Quality Quorum]

On Thu, 22 Aug 2002, Andrew Cagney wrote:

> Lets get rid of the easy one (...) `Hg':
>
> ``
>
> @item @code{Hg}@var{id} --- set general thread
> @cindex @code{Hc} packet
>
> Select the general thread.  Register and memory read and write
> operations apply to the most recently selected general thread.


????? Memory is shared between threads, isn't it so ????

IMHO, a multi-process debugging is a very different animal from a
multi-thread debugging and lumping them together only creates more
problems.

Thanks,

Aleksey



> @var{id}, a hex encoded cardinal, is the identifier of the selected thread.
>
> After a target stop, the general thread is reset to the thread
> identifier of the stopped thread.
>
> @emph{Implementation note:  The @code{Hg} packet can not be used to
> determine the most recently selected thread (using the @samp{thread
> @var{thread-id} command).  This is because @value{GDBN} can cache
> per-thread data and avoid the need to re-query the target on each
> @samp{thread} command.}
>
> @c Note the word ``can'' is used, not ``does'' :-)
>
> Reply:
> @table @samp
> @item OK
> for success
> @item E00
> unspecified error
> @c ESRCH --- no such proces/thread?
> @item @samp{}
> unsupported
> @end table
>
> ''
>
> Andrew
>
>
> > On Fri, Aug 16, 2002 at 10:42:42AM -0400, Andrew Cagney wrote:
> >
> >> >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
> >
> >
> > Hc<PID> has a definite meaning right now.  It means, step ONLY this
> > thread.  That corresponds to set scheduler-locking (on|step).  Hc0 will
> > be sent if we are not using scheduler locking.
> >
> > I see nothing wrong with the current meaning of Hc.
> >
> > Also, Hs was never meant to INCLUDE the step command.  It sets a thread
> > context, that's all.
> >
> >
> >> >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.
> >
> >
> > As above.
> >
> >
> >> >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.
> >
> >
> > We need two thread markers to step correctly; I think using this one is
> > more logical.  If you prefer then the code in gdbserver to use Hs is
> > already there.
> >
> >
> >> 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).
> >
> >
> > No, actually, gdbserver is what gets confused.  You've said this
> > several times, and the last time you said it I went to check.  In all
> > my tests, both local (lin-lwp) and remote (with Hs patch), everything
> > stepped the selected thread gracefully.  This already works.  Even
> > scheduler locking works.
> >
> > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
>
>

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Fri, Aug 23, 2002 at 10:24:28AM -0400, Quality Quorum wrote:
> 
> 
> On Thu, 22 Aug 2002, Andrew Cagney wrote:
> 
> > Lets get rid of the easy one (...) `Hg':
> >
> > ``
> >
> > @item @code{Hg}@var{id} --- set general thread
> > @cindex @code{Hc} packet
> >
> > Select the general thread.  Register and memory read and write
> > operations apply to the most recently selected general thread.
> 
> 
> ????? Memory is shared between threads, isn't it so ????
> 
> IMHO, a multi-process debugging is a very different animal from a
> multi-thread debugging and lumping them together only creates more
> problems.

Registers aren't, though.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Two small remote protocol extensions

[Quality Quorum]

On Fri, 23 Aug 2002, Daniel Jacobowitz wrote:

> On Fri, Aug 23, 2002 at 10:24:28AM -0400, Quality Quorum wrote:
> >
> >
> > On Thu, 22 Aug 2002, Andrew Cagney wrote:
> >
> > > Lets get rid of the easy one (...) `Hg':
> > >
> > > ``
> > >
> > > @item @code{Hg}@var{id} --- set general thread
> > > @cindex @code{Hc} packet
> > >
> > > Select the general thread.  Register and memory read and write
> > > operations apply to the most recently selected general thread.
> >
> >
> > ????? Memory is shared between threads, isn't it so ????
> >
> > IMHO, a multi-process debugging is a very different animal from a
> > multi-thread debugging and lumping them together only creates more
> > problems.
>
> Registers aren't, though.

??? It seems to me that  I was not talking about registers ???

>
> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer
>

Thanks,

Aleksey

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> On Thu, 22 Aug 2002, Andrew Cagney wrote:
> 
> 
>> Lets get rid of the easy one (...) `Hg':
>>
>> ``
>>
>> @item @code{Hg}@var{id} --- set general thread
>> @cindex @code{Hc} packet
>>
>> Select the general thread.  Register and memory read and write
>> operations apply to the most recently selected general thread.


> ????? Memory is shared between threads, isn't it so ????

The above reflects GDB's current behavour (logical or not).

When reading or writing memory, gdb specifies a thread.  If it turns out 
that the thread disappeared, GDB picks a thread, any thread (the 
assumption being that all address spaces are pretty much similar).

Mind you, I've seen thread implementations that implemented per-thread 
local data using VM.

enjoy,
Andrew


> IMHO, a multi-process debugging is a very different animal from a
> multi-thread debugging and lumping them together only creates more
> problems.
> 
> Thanks,
> 
> Aleksey
> 
> 
> 
> 
>> @var{id}, a hex encoded cardinal, is the identifier of the selected thread.
>>
>> After a target stop, the general thread is reset to the thread
>> identifier of the stopped thread.
>>
>> @emph{Implementation note:  The @code{Hg} packet can not be used to
>> determine the most recently selected thread (using the @samp{thread
>> @var{thread-id} command).  This is because @value{GDBN} can cache
>> per-thread data and avoid the need to re-query the target on each
>> @samp{thread} command.}
>>
>> @c Note the word ``can'' is used, not ``does'' :-)
>>
>> Reply:
>> @table @samp
>> @item OK
>> for success
>> @item E00
>> unspecified error
>> @c ESRCH --- no such proces/thread?
>> @item @samp{}
>> unsupported
>> @end table
>>
>> ''
>>
>> Andrew
>>
>>
> 
>> > On Fri, Aug 16, 2002 at 10:42:42AM -0400, Andrew Cagney wrote:
>> >
> 
>> >> >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
> 
>> >
>> >
>> > Hc<PID> has a definite meaning right now.  It means, step ONLY this
>> > thread.  That corresponds to set scheduler-locking (on|step).  Hc0 will
>> > be sent if we are not using scheduler locking.
>> >
>> > I see nothing wrong with the current meaning of Hc.
>> >
>> > Also, Hs was never meant to INCLUDE the step command.  It sets a thread
>> > context, that's all.
>> >
>> >
> 
>> >> >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.
> 
>> >
>> >
>> > As above.
>> >
>> >
> 
>> >> >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.
> 
>> >
>> >
>> > We need two thread markers to step correctly; I think using this one is
>> > more logical.  If you prefer then the code in gdbserver to use Hs is
>> > already there.
>> >
>> >
> 
>> >> 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).
> 
>> >
>> >
>> > No, actually, gdbserver is what gets confused.  You've said this
>> > several times, and the last time you said it I went to check.  In all
>> > my tests, both local (lin-lwp) and remote (with Hs patch), everything
>> > stepped the selected thread gracefully.  This already works.  Even
>> > scheduler locking works.
>> >
>> > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
> 
>>
>>

Re: RFC: Two small remote protocol extensions

[Quality Quorum]

On Fri, 23 Aug 2002, Andrew Cagney wrote:

> > On Thu, 22 Aug 2002, Andrew Cagney wrote:
> >
> >
> >> Lets get rid of the easy one (...) `Hg':
> >>
> >> ``
> >>
> >> @item @code{Hg}@var{id} --- set general thread
> >> @cindex @code{Hc} packet
> >>
> >> Select the general thread.  Register and memory read and write
> >> operations apply to the most recently selected general thread.
>
>
> > ????? Memory is shared between threads, isn't it so ????
>
> The above reflects GDB's current behavour (logical or not).

This is yet another long overdue problem (I had hope it was fixed in
recent releases) -  gdb lumps together mult-process
debugging with multi-tread debugging and it it does not
excell in any of them.

It seems to me that we have to handle multi-process debugging a-la
vxWorks with a separate gdb instance per process and thus forget about it.

>
> When reading or writing memory, gdb specifies a thread.  If it turns out
> that the thread disappeared, GDB picks a thread, any thread (the
> assumption being that all address spaces are pretty much similar).
>
> Mind you, I've seen thread implementations that implemented per-thread
> local data using VM.

It does not mean that everybody else should suffer, it is time to fix
this youthful indiscretion.

>
> enjoy,
> Andrew

Thanks,

Aleksey

>
>
> > IMHO, a multi-process debugging is a very different animal from a
> > multi-thread debugging and lumping them together only creates more
> > problems.
> >
> > Thanks,
> >
> > Aleksey
> >
> >
> >
> >
> >> @var{id}, a hex encoded cardinal, is the identifier of the selected thread.
> >>
> >> After a target stop, the general thread is reset to the thread
> >> identifier of the stopped thread.
> >>
> >> @emph{Implementation note:  The @code{Hg} packet can not be used to
> >> determine the most recently selected thread (using the @samp{thread
> >> @var{thread-id} command).  This is because @value{GDBN} can cache
> >> per-thread data and avoid the need to re-query the target on each
> >> @samp{thread} command.}
> >>
> >> @c Note the word ``can'' is used, not ``does'' :-)
> >>
> >> Reply:
> >> @table @samp
> >> @item OK
> >> for success
> >> @item E00
> >> unspecified error
> >> @c ESRCH --- no such proces/thread?
> >> @item @samp{}
> >> unsupported
> >> @end table
> >>
> >> ''
> >>
> >> Andrew
> >>
> >>
> >
> >> > On Fri, Aug 16, 2002 at 10:42:42AM -0400, Andrew Cagney wrote:
> >> >
> >
> >> >> >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
> >
> >> >
> >> >
> >> > Hc<PID> has a definite meaning right now.  It means, step ONLY this
> >> > thread.  That corresponds to set scheduler-locking (on|step).  Hc0 will
> >> > be sent if we are not using scheduler locking.
> >> >
> >> > I see nothing wrong with the current meaning of Hc.
> >> >
> >> > Also, Hs was never meant to INCLUDE the step command.  It sets a thread
> >> > context, that's all.
> >> >
> >> >
> >
> >> >> >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.
> >
> >> >
> >> >
> >> > As above.
> >> >
> >> >
> >
> >> >> >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.
> >
> >> >
> >> >
> >> > We need two thread markers to step correctly; I think using this one is
> >> > more logical.  If you prefer then the code in gdbserver to use Hs is
> >> > already there.
> >> >
> >> >
> >
> >> >> 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).
> >
> >> >
> >> >
> >> > No, actually, gdbserver is what gets confused.  You've said this
> >> > several times, and the last time you said it I went to check.  In all
> >> > my tests, both local (lin-lwp) and remote (with Hs patch), everything
> >> > stepped the selected thread gracefully.  This already works.  Even
> >> > scheduler locking works.
> >> >
> >> > -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer
> >
> >>
> >>
>
>

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

>> > ????? Memory is shared between threads, isn't it so ????


> This is yet another long overdue problem (I had hope it was fixed in
> recent releases) -  gdb lumps together mult-process
> debugging with multi-tread debugging and it it does not
> excell in any of them.

You mean GNU/Linux?

> It seems to me that we have to handle multi-process debugging a-la
> vxWorks with a separate gdb instance per process and thus forget about it.

I guess you didn't mean GNU/Linux.

The GNU/Linux and Solaris thread implementation have a specific thread 
that they use when doing memory operations.  That behavour should 
certainly be extended across the remote protocol so that a remote server 
can more exactly mimic the behavour of a native GDB.  GDB's view of the 
target's address space is defined by what the target's process can see. 
  If the target's process can't see it, neither can GDB.

Should it be defined by ``Hg'' I guess that open to debate (current 
implementation doesn't do anything here).  However, I think it should be 
well defined.

> When reading or writing memory, gdb specifies a thread.  If it turns out
>> that the thread disappeared, GDB picks a thread, any thread (the
>> assumption being that all address spaces are pretty much similar).
>>
>> Mind you, I've seen thread implementations that implemented per-thread
>> local data using VM.
> 
> 
> It does not mean that everybody else should suffer, it is time to fix
> this youthful indiscretion.

Humor me.  So who is suffering?

Andrew

Re: RFC: Two small remote protocol extensions

[Quality Quorum]

On Fri, 23 Aug 2002, Andrew Cagney wrote:

>
> >> > ????? Memory is shared between threads, isn't it so ????
>
>
> > This is yet another long overdue problem (I had hope it was fixed in
> > recent releases) -  gdb lumps together mult-process
> > debugging with multi-tread debugging and it it does not
> > excell in any of them.
>
> You mean GNU/Linux?
>
> > It seems to me that we have to handle multi-process debugging a-la
> > vxWorks with a separate gdb instance per process and thus forget about it.
>
> I guess you didn't mean GNU/Linux.
>
> The GNU/Linux and Solaris thread implementation have a specific thread
> that they use when doing memory operations.  That behavour should
> certainly be extended across the remote protocol so that a remote server
> can more exactly mimic the behavour of a native GDB.  GDB's view of the
> target's address space is defined by what the target's process can see.
>   If the target's process can't see it, neither can GDB.
>
> Should it be defined by ``Hg'' I guess that open to debate (current
> implementation doesn't do anything here).  However, I think it should be
> well defined.
>
> > When reading or writing memory, gdb specifies a thread.  If it turns out
> >> that the thread disappeared, GDB picks a thread, any thread (the
> >> assumption being that all address spaces are pretty much similar).
> >>
> >> Mind you, I've seen thread implementations that implemented per-thread
> >> local data using VM.
> >
> >
> > It does not mean that everybody else should suffer, it is time to fix
> > this youthful indiscretion.
>
> Humor me.  So who is suffering?

All things embedded and I suppose it is a much bigger market/user group
than ***ix one.

>
> Andrew
>
>

Thanks,

Aleksey

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

>> > When reading or writing memory, gdb specifies a thread.  If it turns out
> 
>> >> that the thread disappeared, GDB picks a thread, any thread (the
>> >> assumption being that all address spaces are pretty much similar).
>> >>
>> >> Mind you, I've seen thread implementations that implemented per-thread
>> >> local data using VM.
> 
>> >
>> >
>> > It does not mean that everybody else should suffer, it is time to fix
>> > this youthful indiscretion.
> 
>>
>> Humor me.  So who is suffering?
> 
> 
> All things embedded and I suppose it is a much bigger market/user group
> than ***ix one.

Why are ``all things embedded'' suffering?

I know of two cases:

a) The threads have a 100% shared address space.  Binding memory 
accesses to a thread will make zero difference.

b) The threads do not have a 100% shared address space.  Binding memory 
accesses to a thread will at least make it better reflect GDB's view of 
a threads address space.

Andrew

Re: RFC: Two small remote protocol extensions

[Quality Quorum]

On Tue, 27 Aug 2002, Andrew Cagney wrote:

>
> >> > When reading or writing memory, gdb specifies a thread.  If it turns out
> >
> >> >> that the thread disappeared, GDB picks a thread, any thread (the
> >> >> assumption being that all address spaces are pretty much similar).
> >> >>
> >> >> Mind you, I've seen thread implementations that implemented per-thread
> >> >> local data using VM.
> >
> >> >
> >> >
> >> > It does not mean that everybody else should suffer, it is time to fix
> >> > this youthful indiscretion.
> >
> >>
> >> Humor me.  So who is suffering?
> >
> >
> > All things embedded and I suppose it is a much bigger market/user group
> > than ***ix one.
>
> Why are ``all things embedded'' suffering?
>
> I know of two cases:
>
> a) The threads have a 100% shared address space.  Binding memory
> accesses to a thread will make zero difference.
>
> b) The threads do not have a 100% shared address space.  Binding memory
> accesses to a thread will at least make it better reflect GDB's view of
> a threads address space.
>

Forcing model (b) on underlying environment (a) will force unnecessary
invalidations of memory cache and will pretty negatively affect
performance of a debugging session.

I would perefer to treat (b) as a separate process (and run separate gdb
instance to debug it a-la vxWorks and normal multi process debugging),
however, it will be fine to make this thing a configurable run time
parameter. At the sime time of forcing (a) to emulate (b) does not seem
appropriate.

> Andrew
>
>

Thanks,

Aleksey

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> It does not mean that everybody else should suffer, it is time to fix
>> >> > this youthful indiscretion.
> 
>> >
> 
>> >>
>> >> Humor me.  So who is suffering?
> 
>> >
>> >
>> > All things embedded and I suppose it is a much bigger market/user group
>> > than ***ix one.
> 
>>
>> Why are ``all things embedded'' suffering?
>>
>> I know of two cases:
>>
>> a) The threads have a 100% shared address space.  Binding memory
>> accesses to a thread will make zero difference.
>>
>> b) The threads do not have a 100% shared address space.  Binding memory
>> accesses to a thread will at least make it better reflect GDB's view of
>> a threads address space.
>>
> 
> 
> Forcing model (b) on underlying environment (a) will force unnecessary
> invalidations of memory cache and will pretty negatively affect
> performance of a debugging session.

I don't believe that it is even possible to measure a cache effect when 
profiling GDB's single step performance(1) --- other, far bigger, host 
or host<->target things things will drown any cache effects.

Anyway, in case (a), since GDB won't be able to detect which thread was 
used to do the read --- the target is still free to use a thread, any 
thread.

> I would perefer to treat (b) as a separate process (and run separate gdb
> instance to debug it a-la vxWorks and normal multi process debugging),
> however, it will be fine to make this thing a configurable run time
> parameter. At the sime time of forcing (a) to emulate (b) does not seem
> appropriate.

A target is always free to implement (b) using separate GDBs.

Andrew

(1) Above and beyond anything else, this is what a user wants to be fast.

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Wed, Aug 28, 2002 at 12:44:53PM -0400, Andrew Cagney wrote:
> >It does not mean that everybody else should suffer, it is time to fix
> >>>> > this youthful indiscretion.
> >
> >>>
> >
> >>>>
> >>>> Humor me.  So who is suffering?
> >
> >>>
> >>>
> >>> All things embedded and I suppose it is a much bigger market/user group
> >>> than ***ix one.
> >
> >>
> >>Why are ``all things embedded'' suffering?
> >>
> >>I know of two cases:
> >>
> >>a) The threads have a 100% shared address space.  Binding memory
> >>accesses to a thread will make zero difference.
> >>
> >>b) The threads do not have a 100% shared address space.  Binding memory
> >>accesses to a thread will at least make it better reflect GDB's view of
> >>a threads address space.
> >>
> >
> >
> >Forcing model (b) on underlying environment (a) will force unnecessary
> >invalidations of memory cache and will pretty negatively affect
> >performance of a debugging session.
> 
> I don't believe that it is even possible to measure a cache effect when 
> profiling GDB's single step performance(1) --- other, far bigger, host 
> or host<->target things things will drown any cache effects.
> 
> Anyway, in case (a), since GDB won't be able to detect which thread was 
> used to do the read --- the target is still free to use a thread, any 
> thread.

I assume he meant GDB's dcache.  Which is a real lifesaver, except when
it actually slows things down.

> >I would perefer to treat (b) as a separate process (and run separate gdb
> >instance to debug it a-la vxWorks and normal multi process debugging),
> >however, it will be fine to make this thing a configurable run time
> >parameter. At the sime time of forcing (a) to emulate (b) does not seem
> >appropriate.
> 
> A target is always free to implement (b) using separate GDBs.

This is certainly true.  HP even has fragmented code to do it natively.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

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

I think it is passed down when schedule locking and when doing a thread hop.

I'm wondering how native thread implementations handle your case?  I 
don't see how remote_resume(), or any of the other resume functions can 
know which thread to step since the only parameter available to them is 
resume-ptid and you're indicating that that is NULL.

Andrew

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Fri, Aug 23, 2002 at 12:08:29AM -0400, Andrew Cagney wrote:
> 
> >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.
> 
> I think it is passed down when schedule locking and when doing a thread hop.

?  I don't believe so, but I'm not sure what you mean exactly.

> I'm wondering how native thread implementations handle your case?  I 
> don't see how remote_resume(), or any of the other resume functions can 
> know which thread to step since the only parameter available to them is 
> resume-ptid and you're indicating that that is NULL.

Inferior_ptid is set in this case.  That's the whole problem; they have
access to it, but the remote implementation doesn't.  The code from
lin-lwp:

  /* Apparently the interpretation of PID is dependent on STEP: If
     STEP is non-zero, a specific PID means `step only this process
     id'.  But if STEP is zero, then PID means `continue *all*
     processes, but give the signal only to this one'.  */
  resume_all = (PIDGET (ptid) == -1) || !step;

  if (resume_all)
    iterate_over_lwps (resume_set_callback, NULL);
  else
    iterate_over_lwps (resume_clear_callback, NULL);

  /* If PID is -1, it's the current inferior that should be
     handled specially.  */
  if (PIDGET (ptid) == -1)
    ptid = inferior_ptid;

(I'm not quite sure about that comment; that might want to be revisited
later... there should be a way to continue just one process.  I thought
I remembered that working, but I must have been mistaken.)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> I think it is passed down when schedule locking and when doing a thread hop.
> 
> 
> ?  I don't believe so, but I'm not sure what you mean exactly.
> 

See resume().  A ``thread hop'' refers to the problem of needing to 
single step one thread past its breakpoint while not letting any other 
thread slip through while that break point is pulled.

       if ((step || singlestep_breakpoints_inserted_p) &&
           !breakpoints_inserted && breakpoint_here_p (read_pc ()))
         {
           /* Stepping past a breakpoint without inserting breakpoints.
              Make sure only the current thread gets to step, so that
              other threads don't sneak past breakpoints while they are
              not inserted. */

           resume_ptid = inferior_ptid;
         }

Andrew

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> Inferior_ptid is set in this case.  That's the whole problem; they have
> access to it, but the remote implementation doesn't.  The code from
> lin-lwp:
> 
>   /* Apparently the interpretation of PID is dependent on STEP: If
>      STEP is non-zero, a specific PID means `step only this process
>      id'.  But if STEP is zero, then PID means `continue *all*
>      processes, but give the signal only to this one'.  */
>   resume_all = (PIDGET (ptid) == -1) || !step;
> 
>   if (resume_all)
>     iterate_over_lwps (resume_set_callback, NULL);
>   else
>     iterate_over_lwps (resume_clear_callback, NULL);
> 
>   /* If PID is -1, it's the current inferior that should be
>      handled specially.  */
>   if (PIDGET (ptid) == -1)
>     ptid = inferior_ptid;
> 
> (I'm not quite sure about that comment; that might want to be revisited
> later... there should be a way to continue just one process.  I thought
> I remembered that working, but I must have been mistaken.)

Hmm,

I'm more interested in Solaris (since that target has a thread model 
which allows control of the entire thread group).  With that one, I 
couldn't find an equivalent operation (I've probably missed it.).

It's just really wierd (wrong?) that one layer of GDB thinks that it 
only needs to specify the step thread when doing the thread hop, yet the 
next layer down finds it necessary to always specify the step thread :-?

Andrew

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Fri, Aug 23, 2002 at 03:53:18PM -0400, Andrew Cagney wrote:
> 
> >Inferior_ptid is set in this case.  That's the whole problem; they have
> >access to it, but the remote implementation doesn't.  The code from
> >lin-lwp:
> >
> >  /* Apparently the interpretation of PID is dependent on STEP: If
> >     STEP is non-zero, a specific PID means `step only this process
> >     id'.  But if STEP is zero, then PID means `continue *all*
> >     processes, but give the signal only to this one'.  */
> >  resume_all = (PIDGET (ptid) == -1) || !step;
> >
> >  if (resume_all)
> >    iterate_over_lwps (resume_set_callback, NULL);
> >  else
> >    iterate_over_lwps (resume_clear_callback, NULL);
> >
> >  /* If PID is -1, it's the current inferior that should be
> >     handled specially.  */
> >  if (PIDGET (ptid) == -1)
> >    ptid = inferior_ptid;
> >
> >(I'm not quite sure about that comment; that might want to be revisited
> >later... there should be a way to continue just one process.  I thought
> >I remembered that working, but I must have been mistaken.)
> 
> Hmm,
> 
> I'm more interested in Solaris (since that target has a thread model 
> which allows control of the entire thread group).  With that one, I 
> couldn't find an equivalent operation (I've probably missed it.).

Let me see... sol_thread_resume:
  inferior_ptid = thread_to_lwp (inferior_ptid, PIDGET (main_ph.ptid));

procfs_resume:
  /* Find procinfo for main process */
  pi = find_procinfo_or_die (PIDGET (inferior_ptid), 0);

After that if PIDGET (ptid) == -1, it operates on the procinfo it got
from inferior_ptid.  Which is an LWP.  I'm not sure precisely that will
happen if you resume a specific LWP under Solaris; presumably it will
resume that LWP's "current" thread in some sense, I don't know if that
will behave predictably or not.  I'm not familiar with Solaris threads.

> It's just really wierd (wrong?) that one layer of GDB thinks that it 
> only needs to specify the step thread when doing the thread hop, yet the 
> next layer down finds it necessary to always specify the step thread :-?

Sure.  I suppose we should clean up the interface to resume, to prevent
all this confusion re-arising... which means figuring out our possible
behaviors, and whether they are even implementable on particular
targets.

On Linux the options for any given LWP (at the moment, that means for
any given thread) are step, run, stop.  All combinations are available. 
I think the _useful_ ones are:

  step one, stop others
  step one, continue others
  continue one, stop others
  continue one, continue others

And, of course:
  stop one, stop others
:)

Something like:
  resume (ptid, step, run_others, target_signal)
maybe?  Does anyone think step_all is useful (I don't)?


PS:
Some day letting the user be more precise (run these two threads) would
be nice.  I envision a day in the distant future:
 -> Continue thread 1
 -> Continue thread 2
 -> Wait for inferior status
 <- All threads stopped, thread 1, SIGSEGV
or
 -> Continue all threads
 -> Wait for inferior status [maybe implicit in the all-threads
				request]
 <- Thread 1 stopped, shared lib breakpoint, all other threads running

But let's not try to design to that quite yet :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> Sure.  I suppose we should clean up the interface to resume, to prevent
> all this confusion re-arising... which means figuring out our possible
> behaviors, and whether they are even implementable on particular
> targets.

The spanner in the works here is simulators.  They can't implement 
schedule-locking because their scheduler is hardwired.  The best they 
can manage is step off current instruction.

A simple version of this (PPC) (from memory) always implements 
step->schedule.  If you step I the procesor.  It complets one 
instruction on the current CPU and then schedules the next CPU for the 
next instruction.

> On Linux the options for any given LWP (at the moment, that means for
> any given thread) are step, run, stop.  All combinations are available. 
> I think the _useful_ ones are:
> 
>   step one, stop others
>   step one, continue others
>   continue one, stop others
>   continue one, continue others
> 
> And, of course:
>   stop one, stop others
> :)
> 

What is the absolute minimum needed?

- step off breakpoint / thread-hop
= using a sched lock single-step
= using software single-step breakpoints and a sched lock continue 
(Note: this is where the existing interface really falls down -- step=0 
so remote.c won't know to schedule-lock)

- continue

I think, after that, everything is an efficiency gain.  Looking at the list:

 >   step one, stop others

Hardware single-step off of breakpoint.
TPID, STEP, !OTH
HcTID, s

 >   step one, continue others

Hardware single-step.
TPID, STEP, OTH
H???, s

 >   continue one, stop others

Schedule lock.
Software single-step off breakpoint.
TPID, !STEP, !OTH (wiered)
HcTID, c

 >   continue one, continue others

Software single-step.
General resume.
TPID, !STEP, OTH
Hc0, c

 > Something like:
 >   resume (ptid, step, run_others, target_signal)
 > maybe?  Does anyone think step_all is useful (I don't)?

It is what a simulator might implement.

So looking at the remote protocol.  There in't a way of specifying TPID, 
STEP, OTH (your bug).

Andrew




> PS:
> Some day letting the user be more precise (run these two threads) would
> be nice.  I envision a day in the distant future:
>  -> Continue thread 1
>  -> Continue thread 2
>  -> Wait for inferior status
>  <- All threads stopped, thread 1, SIGSEGV
> or
>  -> Continue all threads
>  -> Wait for inferior status [maybe implicit in the all-threads
> 				request]
>  <- Thread 1 stopped, shared lib breakpoint, all other threads running

Try ``target remote-async''.

> But let's not try to design to that quite yet :)

:-)

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Wed, Aug 28, 2002 at 12:06:38AM -0400, Andrew Cagney wrote:
> 
> >Sure.  I suppose we should clean up the interface to resume, to prevent
> >all this confusion re-arising... which means figuring out our possible
> >behaviors, and whether they are even implementable on particular
> >targets.
> 
> The spanner in the works here is simulators.  They can't implement 
> schedule-locking because their scheduler is hardwired.  The best they 
> can manage is step off current instruction.
> 
> A simple version of this (PPC) (from memory) always implements 
> step->schedule.  If you step I the procesor.  It complets one 
> instruction on the current CPU and then schedules the next CPU for the 
> next instruction.

OK, makes sense.

> >On Linux the options for any given LWP (at the moment, that means for
> >any given thread) are step, run, stop.  All combinations are available. 
> >I think the _useful_ ones are:
> >
> >  step one, stop others
> >  step one, continue others
> >  continue one, stop others
> >  continue one, continue others
> >
> >And, of course:
> >  stop one, stop others
> >:)
> >
> 
> What is the absolute minimum needed?
> 
> - step off breakpoint / thread-hop
> = using a sched lock single-step
> = using software single-step breakpoints and a sched lock continue 
> (Note: this is where the existing interface really falls down -- step=0 
> so remote.c won't know to schedule-lock)
> 
> - continue
> 
> I think, after that, everything is an efficiency gain.  Looking at the list:
> 
> >   step one, stop others
> 
> Hardware single-step off of breakpoint.
> TPID, STEP, !OTH
> HcTID, s
> 
> >   step one, continue others
> 
> Hardware single-step.
> TPID, STEP, OTH
> H???, s
> 
> >   continue one, stop others
> 
> Schedule lock.
> Software single-step off breakpoint.
> TPID, !STEP, !OTH (wiered)
> HcTID, c
> 
> >   continue one, continue others
> 
> Software single-step.
> General resume.
> TPID, !STEP, OTH
> Hc0, c
> 
> > Something like:
> >   resume (ptid, step, run_others, target_signal)
> > maybe?  Does anyone think step_all is useful (I don't)?
> 
> It is what a simulator might implement.
> 
> So looking at the remote protocol.  There in't a way of specifying TPID, 
> STEP, OTH (your bug).

OK, I suppose that makes sense.  It's pretty much where I was to begin
with: if Hc is non-zero, lock to that thread; if Hc is 0, resume all
threads, but where do we step?  How would you like to see us specify
this - I used Hs, a new step packet taking a thread argument might work
too... etc.

There's also the question of whether any other simulators or targets
handle this, and how they behave; I'm not familiar with them.  Do they
treat "HcTID, s" as single-step-one-thread-only?  I guess they probably
do.

> >PS:
> >Some day letting the user be more precise (run these two threads) would
> >be nice.  I envision a day in the distant future:
> > -> Continue thread 1
> > -> Continue thread 2
> > -> Wait for inferior status
> > <- All threads stopped, thread 1, SIGSEGV
> >or
> > -> Continue all threads
> > -> Wait for inferior status [maybe implicit in the all-threads
> >				request]
> > <- Thread 1 stopped, shared lib breakpoint, all other threads running
> 
> Try ``target remote-async''.

Yes, that has the general model that I'm looking for, but this requires
some protocol changes - the protocol would be async-only.  It wouldn't
make sense as a synchronous protocol.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Wed, Aug 28, 2002 at 09:34:45AM -0400, Daniel Jacobowitz wrote:
> On Wed, Aug 28, 2002 at 12:06:38AM -0400, Andrew Cagney wrote:
> > What is the absolute minimum needed?
> > 
> > - step off breakpoint / thread-hop
> > = using a sched lock single-step
> > = using software single-step breakpoints and a sched lock continue 
> > (Note: this is where the existing interface really falls down -- step=0 
> > so remote.c won't know to schedule-lock)
> > 
> > - continue
> > 
> > I think, after that, everything is an efficiency gain.  Looking at the list:
> > 
> > >   step one, stop others
> > 
> > Hardware single-step off of breakpoint.
> > TPID, STEP, !OTH
> > HcTID, s
> > 
> > >   step one, continue others
> > 
> > Hardware single-step.
> > TPID, STEP, OTH
> > H???, s
> > 
> > >   continue one, stop others
> > 
> > Schedule lock.
> > Software single-step off breakpoint.
> > TPID, !STEP, !OTH (wiered)
> > HcTID, c
> > 
> > >   continue one, continue others
> > 
> > Software single-step.
> > General resume.
> > TPID, !STEP, OTH
> > Hc0, c
> > 
> > > Something like:
> > >   resume (ptid, step, run_others, target_signal)
> > > maybe?  Does anyone think step_all is useful (I don't)?
> > 
> > It is what a simulator might implement.
> > 
> > So looking at the remote protocol.  There in't a way of specifying TPID, 
> > STEP, OTH (your bug).
> 
> OK, I suppose that makes sense.  It's pretty much where I was to begin
> with: if Hc is non-zero, lock to that thread; if Hc is 0, resume all
> threads, but where do we step?  How would you like to see us specify
> this - I used Hs, a new step packet taking a thread argument might work
> too... etc.
> 
> There's also the question of whether any other simulators or targets
> handle this, and how they behave; I'm not familiar with them.  Do they
> treat "HcTID, s" as single-step-one-thread-only?  I guess they probably
> do.

Andrew,

I was reminded today that this bug is still present, and we haven't
come up with a solution for it.  Do you have any ideas?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> 
> Andrew,
> 
> I was reminded today that this bug is still present, and we haven't
> come up with a solution for it.  Do you have any ideas?

The entire thread is in my inbox for be to go back through (so I've not 
dropped it entirely).

Andrew

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> OK, I suppose that makes sense.  It's pretty much where I was to begin
> with: if Hc is non-zero, lock to that thread; if Hc is 0, resume all
> threads, but where do we step?  How would you like to see us specify
> this - I used Hs, a new step packet taking a thread argument might work
> too... etc.

Yes, to come full circle, I can see two choices:

- (me back down) and Hg be made as per your proposal - as well as the 
registers, it also specify the thread to step when there isn't thread 
locking.

- we define something properly

- we modify GDB so that, when asked to step a thread other than current 
(i.e., selected) GDB first forces the target to switch to that thread, 
and then steps it.  This means doing a software single step even though 
the hardware might think it has hardware single step.

Separate to this GDB needs to be changed to that resume() has all the 
information it needs to implement all of the above operations (and it 
isn't relying on that implied global state :-( ).

 >
 > There's also the question of whether any other simulators or targets
 > handle this, and how they behave; I'm not familiar with them.  Do they
 > treat "HcTID, s" as single-step-one-thread-only?  I guess they probably
 > do.

I really don't know.  (For ``s'', should you be stepping all threads?)

Anyway, I think, to do this right, we're left needing a new packet.  Try:


 >> >   step one, stop others
 >
 >>
 >> Hardware single-step off of breakpoint.
 >> TPID, STEP, !OTH
 >> HcTID, s

HtTID;s

 >> >   step one, continue others
 >
 >>
 >> Hardware single-step.
 >> TPID, STEP, OTH
 >> H???, s

HtPID,0;s
	or even:
Ht0;s
	I.e., step all threads.  Let GDB sort out the mess.

 >> >   continue one, stop others
 >
 >>
 >> Schedule lock.
 >> Software single-step off breakpoint.
 >> TPID, !STEP, !OTH (wiered)
 >> HcTID, c

HtTID;c

 >> >   continue one, continue others
 >
 >>
 >> Software single-step.
 >> General resume.
 >> TPID, !STEP, OTH
 >> Hc0, c

Ht0;c
	or
c

And also:

HtTID;g
HtTID,TID,TID;Z...
HtTID,TID,TID;c

etc.

Andrew

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> - we modify GDB so that, when asked to step a thread other than current (i.e., selected) GDB first forces the target to switch to that thread, and then steps it.  This means doing a software single step even though the hardware might think it has hardware single step.

To, er, make things up as I go along;

Should the target code iterate through the thread db to find out what it 
is ment to do with each thread?

Down the road, I don't see any other (easy) way of getting something 
like a ``thread suspend'' working.  A schedule lock is really suspend 
all but selected.

Andrew

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

Going back through my inbox, I definitely dropped the ball on this one. 
Oops!

Here's a test case I just wrote, if you want to experiment with the
issue:

#include <pthread.h>

void foo (void)
{
}

void *thread_func (void *arg)
{
  int x;
  for (x = 0; x < 10; x++)
    foo ();
  return 0;
}

int main()
{
  pthread_t thr;
  void *ret;
  int x;

  pthread_create (&thr, NULL, thread_func, NULL);
  pthread_join (thr, &ret);
  for (x = 0; x < 10; x++)
    foo ();  
}


Compile, debug.  Set breakpoint on thread_func.  Say "next".  Native
GDB will do the obvious thing and step into the for loop.  Gdbserver
will switch to the first thread and report that we're stopped in
sigsuspend, one single-step off of the syscall.  My premise is that
GDB's behavior is correct.

On Thu, Sep 26, 2002 at 09:39:50PM -0400, Andrew Cagney wrote:
> 
> >OK, I suppose that makes sense.  It's pretty much where I was to begin
> >with: if Hc is non-zero, lock to that thread; if Hc is 0, resume all
> >threads, but where do we step?  How would you like to see us specify
> >this - I used Hs, a new step packet taking a thread argument might work
> >too... etc.
> 
> Yes, to come full circle, I can see two choices:
> 
> - (me back down) and Hg be made as per your proposal - as well as the 
> registers, it also specify the thread to step when there isn't thread 
> locking.

For the record, since I had to go look it up: this was the suggestion
that we use Hg to communicate the "selected" thread before doing a
non-scheduler-locked single step.

> - we define something properly

And this defining some other way to convey that information.

> > There's also the question of whether any other simulators or targets
> > handle this, and how they behave; I'm not familiar with them.  Do they
> > treat "HcTID, s" as single-step-one-thread-only?  I guess they probably
> > do.
> 
> I really don't know.  (For ``s'', should you be stepping all threads?)
> 
> Anyway, I think, to do this right, we're left needing a new packet.  Try:
> 
> 
> >> >   step one, stop others
> >
> >>
> >> Hardware single-step off of breakpoint.
> >> TPID, STEP, !OTH
> >> HcTID, s
> 
> HtTID;s

HtTID;s - single step just this thread.

> >> >   step one, continue others
> >
> >>
> >> Hardware single-step.
> >> TPID, STEP, OTH
> >> H???, s
> 
> HtPID,0;s
> 	or even:
> Ht0;s
> 	I.e., step all threads.  Let GDB sort out the mess.

What happened to step-one-continue-others?  I don't think step-all is
particularly useful.  Step-one-continue-others has its issues, but I
can see definite times when it is useful - for instance when one thread
makes a syscall which waits on a mutex.

The HtTID approach doesn't seem to say how other threads should be
treated.  Do we want:
 HtTIDs		step one
 HtTIDs;0c	step one cont others
 HtTIDc		cont one

et cetera?

Maybe allow:
 HtTID,TID,TIDs;0c

[Is 0 a valid TID?]

Could we deprecate Hg/Hc in favor of this, to avoid specifying all the
interactions?

And is there any hope of fixing this in 6.0? :(((

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> et cetera?
> 
> Maybe allow:
>  HtTID,TID,TIDs;0c

I don't think this case can arise.  Well at least not immediatly.  A 
`hey we're thinking in this direction' comment wouldn't hurt though.

> [Is 0 a valid TID?]

GDB doesn't think it is (which can give targets grief :-/).  However, it 
could be a [sc] without the "0".

> Could we deprecate Hg/Hc in favor of this, to avoid specifying all the
> interactions?
> 
> And is there any hope of fixing this in 6.0? :(((

Maybe 6.0.1.

Hmm, why are we even fighting with the H packet?  The senario is GDB 
telling the target to resume in more weird and more wonderful ways.

- single step a thread
- continue a thread
- step out of range a thread
- signal a thread
- continue or freeze remaining threads

can GDB simply grab a new letter and spec out it's real intent?

Andrew

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Wed, Sep 03, 2003 at 07:41:28PM -0400, Andrew Cagney wrote:
> 
> >et cetera?
> >
> >Maybe allow:
> > HtTID,TID,TIDs;0c
> 
> I don't think this case can arise.  Well at least not immediatly.  A 
> `hey we're thinking in this direction' comment wouldn't hurt though.
> 
> >[Is 0 a valid TID?]
> 
> GDB doesn't think it is (which can give targets grief :-/).  However, it 
> could be a [sc] without the "0".
> 
> >Could we deprecate Hg/Hc in favor of this, to avoid specifying all the
> >interactions?
> >
> >And is there any hope of fixing this in 6.0? :(((
> 
> Maybe 6.0.1.
> 
> Hmm, why are we even fighting with the H packet?  The senario is GDB 
> telling the target to resume in more weird and more wonderful ways.
> 
> - single step a thread
> - continue a thread
> - step out of range a thread
> - signal a thread
> - continue or freeze remaining threads
> 
> can GDB simply grab a new letter and spec out it's real intent?

Well, Ht is effectively a new letter - H is only defined for c and g.
We could explicitly state that, or look for a new letter.  I recommend
a multi-letter sequence, the extra bytes don't matter and we don't have
all that many letters.

To summarize, here's what we seem to have now natively:
  - Single step one thread, all others stopped.
  - Single step one thread, all others continued.
  - Signal one thread, all others stopped.
  - Signal one thread, all others continued.
  - Continue all threads.

Here's what I think would be useful, though:
  - Per thread, specify stopped/singlestepped/signal/continue.

Some of the combinations aren't useful; singlestepping multiple threads
for instance is not usually useful.  Well, I suppose it could be.

But specific signals to multiple threads at the same time (well, same
time is really kind of approximate without better native interfaces...)
- now that's useful in debugging race conditions.

So, do you agree?  If so, here's just one possible way to implement it. 
I left it as Ht because I'm too lazy to go find another letter.  This
doesn't include step out of range because I'm not sure how that should
look (what was the problem with step out of range anyway?  That caused
it to get disabled? - and its current syntax is not in the manual).

  Ht 'TID' 'DISPOSITION' [';' 'TID' 'DISPOSITION']... [';' 'DISPOSITION']

'TID' should be a numeric thread ID, to affect one thread.

'DISPOSITION' can be:
  's'
  'c'
  'C' 'SIGNAL'

A final 'DISPOSITION' is applied to all threads not explicitly listed.

Note that this Ht is a continue packet, not a select-thread packet.  So
Ht is not a good choice.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> Well, Ht is effectively a new letter - H is only defined for c and g.
> We could explicitly state that, or look for a new letter.  I recommend
> a multi-letter sequence, the extra bytes don't matter and we don't have
> all that many letters.

Definitly a multi-letter sequence, but a new letter :-)

> To summarize, here's what we seem to have now natively:
>   - Single step one thread, all others stopped.
>   - Single step one thread, all others continued.
>   - Signal one thread, all others stopped.
>   - Signal one thread, all others continued.
>   - Continue all threads.
> 
> Here's what I think would be useful, though:
>   - Per thread, specify stopped/singlestepped/signal/continue.
> 
> Some of the combinations aren't useful; singlestepping multiple threads
> for instance is not usually useful.  Well, I suppose it could be.

Who are we to argue :-)

> But specific signals to multiple threads at the same time (well, same
> time is really kind of approximate without better native interfaces...)
> - now that's useful in debugging race conditions.
> 
> So, do you agree?  If so, here's just one possible way to implement it. 
> I left it as Ht because I'm too lazy to go find another letter.  This
> doesn't include step out of range because I'm not sure how that should
> look (what was the problem with step out of range anyway?  That caused
> it to get disabled? - and its current syntax is not in the manual).

It wasn't thread friendly, wasn't documented, it wasn't consistent with 
the other continuation packets (it had two replies).

>   Ht 'TID' 'DISPOSITION' [';' 'TID' 'DISPOSITION']... [';' 'DISPOSITION']
> 
> 'TID' should be a numeric thread ID, to affect one thread.
> 
> 'DISPOSITION' can be:
>   's'
>   'c'
>   'C' 'SIGNAL'

I hope TID is decimal :-)

> A final 'DISPOSITION' is applied to all threads not explicitly listed.
> 
> Note that this Ht is a continue packet, not a select-thread packet.  So
> Ht is not a good choice.

Yep.

Andrew

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Wed, Sep 17, 2003 at 12:19:35PM -0400, Andrew Cagney wrote:
> 
> >Well, Ht is effectively a new letter - H is only defined for c and g.
> >We could explicitly state that, or look for a new letter.  I recommend
> >a multi-letter sequence, the extra bytes don't matter and we don't have
> >all that many letters.
> 
> Definitly a multi-letter sequence, but a new letter :-)
> 
> >To summarize, here's what we seem to have now natively:
> >  - Single step one thread, all others stopped.
> >  - Single step one thread, all others continued.
> >  - Signal one thread, all others stopped.
> >  - Signal one thread, all others continued.
> >  - Continue all threads.
> >
> >Here's what I think would be useful, though:
> >  - Per thread, specify stopped/singlestepped/signal/continue.
> >
> >Some of the combinations aren't useful; singlestepping multiple threads
> >for instance is not usually useful.  Well, I suppose it could be.
> 
> Who are we to argue :-)

Heh.

> >But specific signals to multiple threads at the same time (well, same
> >time is really kind of approximate without better native interfaces...)
> >- now that's useful in debugging race conditions.
> >
> >So, do you agree?  If so, here's just one possible way to implement it. 
> >I left it as Ht because I'm too lazy to go find another letter.  This
> >doesn't include step out of range because I'm not sure how that should
> >look (what was the problem with step out of range anyway?  That caused
> >it to get disabled? - and its current syntax is not in the manual).
> 
> It wasn't thread friendly, wasn't documented, it wasn't consistent with 
> the other continuation packets (it had two replies).

OK.  I think there's room to add it to something like this, so I'm not
gonna fret about it for now.

> >  Ht 'TID' 'DISPOSITION' [';' 'TID' 'DISPOSITION']... [';' 'DISPOSITION']
> >
> >'TID' should be a numeric thread ID, to affect one thread.
> >
> >'DISPOSITION' can be:
> >  's'
> >  'c'
> >  'C' 'SIGNAL'
> 
> I hope TID is decimal :-)

Heh, 'c', right.  Any objection to using decimal thread IDs, or would
you rather have 'TID' : 'DISPOSITION' ; ... ?

> >A final 'DISPOSITION' is applied to all threads not explicitly listed.
> >
> >Note that this Ht is a continue packet, not a select-thread packet.  So
> >Ht is not a good choice.
> 
> Yep.

How about, um, "vCont"?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

> OK.  I think there's room to add it to something like this, so I'm not
> gonna fret about it for now.
> 
> 
>> >  Ht 'TID' 'DISPOSITION' [';' 'TID' 'DISPOSITION']... [';' 'DISPOSITION']
>> >
>> >'TID' should be a numeric thread ID, to affect one thread.
>> >
>> >'DISPOSITION' can be:
>> >  's'
>> >  'c'
>> >  'C' 'SIGNAL'
> 
>> 
>> I hope TID is decimal :-)

Hmm, I think it should be more LL1, which the above (and the remote 
protocol :-) isn't.  Something like:

c:TID
s:TID
C:SIG:TID

that way someone can later add:

p:REG:VALUE

Oh and TID is hex:

      if (strncmp (p, "thread", p1 - p) == 0)
        {
          p_temp = unpack_varlen_hex (++p1, &thread_num);

 > by @code{REGISTER_RAW_SIZE}; @var{n...} = @samp{thread}, @var{r...} =
 > thread process ID, this is a hex integer; @var{n...} = (@samp{watch} |

:-(

> Heh, 'c', right.  Any objection to using decimal thread IDs, or would
> you rather have 'TID' : 'DISPOSITION' ; ... ?
> 
> 
>> >A final 'DISPOSITION' is applied to all threads not explicitly listed.
>> >
>> >Note that this Ht is a continue packet, not a select-thread packet.  So
>> >Ht is not a good choice.
> 
>> 
>> Yep.
> 
> 
> How about, um, "vCont"?

As in:

	vCont;s:456;C04:aba;c

or "n" for "next"

	[n]ext;s:456;C04:aba;c

Main thing is that, the entire leading word must be matched.

The choice, I think, is: a, e, E, f, h, j, J, K, l, L, n, N, o, O, u, U, 
v, V, w, x, y, Y.

(I should mark [eE] has do-not-use).

Andrew

Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz]

On Sun, Sep 21, 2003 at 08:27:32PM -0400, Andrew Cagney wrote:
> 
> >OK.  I think there's room to add it to something like this, so I'm not
> >gonna fret about it for now.
> >
> >
> >>>  Ht 'TID' 'DISPOSITION' [';' 'TID' 'DISPOSITION']... [';' 'DISPOSITION']
> >>>
> >>>'TID' should be a numeric thread ID, to affect one thread.
> >>>
> >>>'DISPOSITION' can be:
> >>>  's'
> >>>  'c'
> >>>  'C' 'SIGNAL'
> >
> >>
> >>I hope TID is decimal :-)
> 
> Hmm, I think it should be more LL1, which the above (and the remote 
> protocol :-) isn't.  Something like:
> 
> c:TID
> s:TID
> C:SIG:TID
> 
> that way someone can later add:
> 
> p:REG:VALUE

What would that mean, anyway?  Since there's no clear thread we're
talking about... it could be p:TID:REG:VALUE but I don't see the use :)

> Oh and TID is hex:
> 
>      if (strncmp (p, "thread", p1 - p) == 0)
>        {
>          p_temp = unpack_varlen_hex (++p1, &thread_num);
> 
> > by @code{REGISTER_RAW_SIZE}; @var{n...} = @samp{thread}, @var{r...} =
> > thread process ID, this is a hex integer; @var{n...} = (@samp{watch} |
> 
> :-(

:(

> >Heh, 'c', right.  Any objection to using decimal thread IDs, or would
> >you rather have 'TID' : 'DISPOSITION' ; ... ?
> >
> >
> >>>A final 'DISPOSITION' is applied to all threads not explicitly listed.
> >>>
> >>>Note that this Ht is a continue packet, not a select-thread packet.  So
> >>>Ht is not a good choice.
> >
> >>
> >>Yep.
> >
> >
> >How about, um, "vCont"?
> 
> As in:
> 
> 	vCont;s:456;C04:aba;c
> 
> or "n" for "next"
> 
> 	[n]ext;s:456;C04:aba;c
> 
> Main thing is that, the entire leading word must be matched.
> 
> The choice, I think, is: a, e, E, f, h, j, J, K, l, L, n, N, o, O, u, U, 
> v, V, w, x, y, Y.
> 
> (I should mark [eE] has do-not-use).

Right, something like that.  As above I guess it would be C:04 instead
of CO4.

I didn't want to take x because of the logical parallel to X.  How
about picking a prefix for all new "long" commands?  I was going to use
v for "verbose".

I'll give this a whirl this week.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Two small remote protocol extensions

[Andrew Cagney]

>> p:REG:VALUE
> 
> 
> What would that mean, anyway?  Since there's no clear thread we're
> talking about... it could be p:TID:REG:VALUE but I don't see the use :)

I do: Don't write anything back until the continue, or a flush vis:

vCont;p:TID:<PC>=ADDR,<NPC>=ADDR;s:TID;c

> Right, something like that.  As above I guess it would be C:04 instead
> of CO4.
> 
> I didn't want to take x because of the logical parallel to X.  How
> about picking a prefix for all new "long" commands?  I was going to use
> v for "verbose".

Ah! Sounds good, doesn't actually mean anything ... :-)

> I'll give this a whirl this week.

Andrew