* RFC: Two small remote protocol extensions @ 2002-05-01 19:25 Daniel Jacobowitz 2002-05-02 8:38 ` Andrew Cagney 2002-08-16 7:30 ` Daniel Jacobowitz 0 siblings, 2 replies; 53+ messages in thread From: Daniel Jacobowitz @ 2002-05-01 19:25 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-01 19:25 RFC: Two small remote protocol extensions Daniel Jacobowitz @ 2002-05-02 8:38 ` Andrew Cagney 2002-05-02 8:52 ` Daniel Jacobowitz 2002-05-02 13:13 ` Quality Quorum 2002-08-16 7:30 ` Daniel Jacobowitz 1 sibling, 2 replies; 53+ messages in thread From: Andrew Cagney @ 2002-05-02 8:38 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-02 8:38 ` Andrew Cagney @ 2002-05-02 8:52 ` Daniel Jacobowitz 2002-05-02 9:39 ` Andrew Cagney 2002-05-02 13:13 ` Quality Quorum 1 sibling, 1 reply; 53+ messages in thread From: Daniel Jacobowitz @ 2002-05-02 8:52 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-02 8:52 ` Daniel Jacobowitz @ 2002-05-02 9:39 ` Andrew Cagney 2002-05-02 12:14 ` Daniel Jacobowitz 0 siblings, 1 reply; 53+ messages in thread From: Andrew Cagney @ 2002-05-02 9:39 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb 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.) ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-02 9:39 ` Andrew Cagney @ 2002-05-02 12:14 ` Daniel Jacobowitz 2002-05-02 12:22 ` Kevin Buettner 2002-05-02 13:13 ` Andrew Cagney 0 siblings, 2 replies; 53+ messages in thread From: Daniel Jacobowitz @ 2002-05-02 12:14 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-02 12:14 ` Daniel Jacobowitz @ 2002-05-02 12:22 ` Kevin Buettner 2002-05-02 12:34 ` Daniel Jacobowitz 2002-05-02 13:13 ` Andrew Cagney 1 sibling, 1 reply; 53+ messages in thread From: Kevin Buettner @ 2002-05-02 12:22 UTC (permalink / raw) To: Daniel Jacobowitz, gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-02 12:22 ` Kevin Buettner @ 2002-05-02 12:34 ` Daniel Jacobowitz 0 siblings, 0 replies; 53+ messages in thread From: Daniel Jacobowitz @ 2002-05-02 12:34 UTC (permalink / raw) To: Kevin Buettner; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-02 12:14 ` Daniel Jacobowitz 2002-05-02 12:22 ` Kevin Buettner @ 2002-05-02 13:13 ` Andrew Cagney 2002-05-02 14:09 ` Daniel Jacobowitz 1 sibling, 1 reply; 53+ messages in thread From: Andrew Cagney @ 2002-05-02 13:13 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-02 13:13 ` Andrew Cagney @ 2002-05-02 14:09 ` Daniel Jacobowitz 2002-05-03 11:24 ` Andrew Cagney 0 siblings, 1 reply; 53+ messages in thread From: Daniel Jacobowitz @ 2002-05-02 14:09 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-02 14:09 ` Daniel Jacobowitz @ 2002-05-03 11:24 ` Andrew Cagney 2002-05-03 14:28 ` Daniel Jacobowitz 0 siblings, 1 reply; 53+ messages in thread From: Andrew Cagney @ 2002-05-03 11:24 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-03 11:24 ` Andrew Cagney @ 2002-05-03 14:28 ` Daniel Jacobowitz 2002-05-03 15:18 ` Andrew Cagney 0 siblings, 1 reply; 53+ messages in thread From: Daniel Jacobowitz @ 2002-05-03 14:28 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-03 14:28 ` Daniel Jacobowitz @ 2002-05-03 15:18 ` Andrew Cagney 2002-05-03 15:22 ` Daniel Jacobowitz 0 siblings, 1 reply; 53+ messages in thread From: Andrew Cagney @ 2002-05-03 15:18 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-03 15:18 ` Andrew Cagney @ 2002-05-03 15:22 ` Daniel Jacobowitz 2002-05-04 19:59 ` Andrew Cagney 0 siblings, 1 reply; 53+ messages in thread From: Daniel Jacobowitz @ 2002-05-03 15:22 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-03 15:22 ` Daniel Jacobowitz @ 2002-05-04 19:59 ` Andrew Cagney 0 siblings, 0 replies; 53+ messages in thread From: Andrew Cagney @ 2002-05-04 19:59 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-02 8:38 ` Andrew Cagney 2002-05-02 8:52 ` Daniel Jacobowitz @ 2002-05-02 13:13 ` Quality Quorum 2002-05-02 14:13 ` Daniel Jacobowitz 2002-05-03 13:07 ` Andrew Cagney 1 sibling, 2 replies; 53+ messages in thread From: Quality Quorum @ 2002-05-02 13:13 UTC (permalink / raw) To: Andrew Cagney; +Cc: Daniel Jacobowitz, gdb 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 > > ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-02 13:13 ` Quality Quorum @ 2002-05-02 14:13 ` Daniel Jacobowitz 2002-05-03 13:07 ` Andrew Cagney 1 sibling, 0 replies; 53+ messages in thread From: Daniel Jacobowitz @ 2002-05-02 14:13 UTC (permalink / raw) To: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-02 13:13 ` Quality Quorum 2002-05-02 14:13 ` Daniel Jacobowitz @ 2002-05-03 13:07 ` Andrew Cagney 1 sibling, 0 replies; 53+ messages in thread From: Andrew Cagney @ 2002-05-03 13:07 UTC (permalink / raw) To: Quality Quorum, Daniel Jacobowitz; +Cc: gdb > > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-05-01 19:25 RFC: Two small remote protocol extensions Daniel Jacobowitz 2002-05-02 8:38 ` Andrew Cagney @ 2002-08-16 7:30 ` Daniel Jacobowitz 2002-08-16 7:42 ` Andrew Cagney 1 sibling, 1 reply; 53+ messages in thread From: Daniel Jacobowitz @ 2002-08-16 7:30 UTC (permalink / raw) To: gdb; +Cc: ac131313 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); ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-16 7:30 ` Daniel Jacobowitz @ 2002-08-16 7:42 ` Andrew Cagney 2002-08-16 7:52 ` Daniel Jacobowitz 0 siblings, 1 reply; 53+ messages in thread From: Andrew Cagney @ 2002-08-16 7:42 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-16 7:42 ` Andrew Cagney @ 2002-08-16 7:52 ` Daniel Jacobowitz 2002-08-16 8:21 ` Andrew Cagney ` (2 more replies) 0 siblings, 3 replies; 53+ messages in thread From: Daniel Jacobowitz @ 2002-08-16 7:52 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-16 7:52 ` Daniel Jacobowitz @ 2002-08-16 8:21 ` Andrew Cagney 2002-08-22 19:23 ` Andrew Cagney 2002-08-22 21:08 ` Andrew Cagney 2 siblings, 0 replies; 53+ messages in thread From: Andrew Cagney @ 2002-08-16 8:21 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb Ulgh, sorry. I'll go and check my notes :-/ Andrew ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-16 7:52 ` Daniel Jacobowitz 2002-08-16 8:21 ` Andrew Cagney @ 2002-08-22 19:23 ` Andrew Cagney 2002-08-22 19:36 ` Daniel Jacobowitz 2002-08-23 7:24 ` Quality Quorum 2002-08-22 21:08 ` Andrew Cagney 2 siblings, 2 replies; 53+ messages in thread From: Andrew Cagney @ 2002-08-22 19:23 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-22 19:23 ` Andrew Cagney @ 2002-08-22 19:36 ` Daniel Jacobowitz 2002-08-23 7:24 ` Quality Quorum 1 sibling, 0 replies; 53+ messages in thread From: Daniel Jacobowitz @ 2002-08-22 19:36 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-22 19:23 ` Andrew Cagney 2002-08-22 19:36 ` Daniel Jacobowitz @ 2002-08-23 7:24 ` Quality Quorum 2002-08-23 7:26 ` Daniel Jacobowitz 2002-08-23 8:57 ` Andrew Cagney 1 sibling, 2 replies; 53+ messages in thread From: Quality Quorum @ 2002-08-23 7:24 UTC (permalink / raw) To: Andrew Cagney; +Cc: Daniel Jacobowitz, gdb 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 > > ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-23 7:24 ` Quality Quorum @ 2002-08-23 7:26 ` Daniel Jacobowitz 2002-08-23 7:49 ` Quality Quorum 2002-08-23 8:57 ` Andrew Cagney 1 sibling, 1 reply; 53+ messages in thread From: Daniel Jacobowitz @ 2002-08-23 7:26 UTC (permalink / raw) To: Quality Quorum; +Cc: Andrew Cagney, gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-23 7:26 ` Daniel Jacobowitz @ 2002-08-23 7:49 ` Quality Quorum 0 siblings, 0 replies; 53+ messages in thread From: Quality Quorum @ 2002-08-23 7:49 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Andrew Cagney, gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-23 7:24 ` Quality Quorum 2002-08-23 7:26 ` Daniel Jacobowitz @ 2002-08-23 8:57 ` Andrew Cagney 2002-08-23 11:16 ` Quality Quorum 1 sibling, 1 reply; 53+ messages in thread From: Andrew Cagney @ 2002-08-23 8:57 UTC (permalink / raw) To: Quality Quorum; +Cc: Daniel Jacobowitz, gdb > 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 > >> >> ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-23 8:57 ` Andrew Cagney @ 2002-08-23 11:16 ` Quality Quorum 2002-08-23 12:39 ` Andrew Cagney 0 siblings, 1 reply; 53+ messages in thread From: Quality Quorum @ 2002-08-23 11:16 UTC (permalink / raw) To: Andrew Cagney; +Cc: Daniel Jacobowitz, gdb 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 > > > >> > >> > > ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-23 11:16 ` Quality Quorum @ 2002-08-23 12:39 ` Andrew Cagney 2002-08-23 13:10 ` Quality Quorum 0 siblings, 1 reply; 53+ messages in thread From: Andrew Cagney @ 2002-08-23 12:39 UTC (permalink / raw) To: Quality Quorum; +Cc: Daniel Jacobowitz, gdb >> > ????? 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-23 12:39 ` Andrew Cagney @ 2002-08-23 13:10 ` Quality Quorum 2002-08-27 20:23 ` Andrew Cagney 0 siblings, 1 reply; 53+ messages in thread From: Quality Quorum @ 2002-08-23 13:10 UTC (permalink / raw) To: Andrew Cagney; +Cc: Daniel Jacobowitz, gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-23 13:10 ` Quality Quorum @ 2002-08-27 20:23 ` Andrew Cagney 2002-08-28 8:31 ` Quality Quorum 0 siblings, 1 reply; 53+ messages in thread From: Andrew Cagney @ 2002-08-27 20:23 UTC (permalink / raw) To: Quality Quorum; +Cc: Daniel Jacobowitz, gdb >> > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-27 20:23 ` Andrew Cagney @ 2002-08-28 8:31 ` Quality Quorum 2002-08-28 9:44 ` Andrew Cagney 0 siblings, 1 reply; 53+ messages in thread From: Quality Quorum @ 2002-08-28 8:31 UTC (permalink / raw) To: Andrew Cagney; +Cc: Daniel Jacobowitz, gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-28 8:31 ` Quality Quorum @ 2002-08-28 9:44 ` Andrew Cagney 2002-08-28 9:49 ` Daniel Jacobowitz 0 siblings, 1 reply; 53+ messages in thread From: Andrew Cagney @ 2002-08-28 9:44 UTC (permalink / raw) To: Quality Quorum; +Cc: Daniel Jacobowitz, gdb > 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. ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-28 9:44 ` Andrew Cagney @ 2002-08-28 9:49 ` Daniel Jacobowitz 0 siblings, 0 replies; 53+ messages in thread From: Daniel Jacobowitz @ 2002-08-28 9:49 UTC (permalink / raw) To: Andrew Cagney; +Cc: Quality Quorum, gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-16 7:52 ` Daniel Jacobowitz 2002-08-16 8:21 ` Andrew Cagney 2002-08-22 19:23 ` Andrew Cagney @ 2002-08-22 21:08 ` Andrew Cagney 2002-08-23 5:44 ` Daniel Jacobowitz 2 siblings, 1 reply; 53+ messages in thread From: Andrew Cagney @ 2002-08-22 21:08 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-22 21:08 ` Andrew Cagney @ 2002-08-23 5:44 ` Daniel Jacobowitz 2002-08-23 12:10 ` Andrew Cagney 2002-08-23 12:53 ` Andrew Cagney 0 siblings, 2 replies; 53+ messages in thread From: Daniel Jacobowitz @ 2002-08-23 5:44 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-23 5:44 ` Daniel Jacobowitz @ 2002-08-23 12:10 ` Andrew Cagney 2002-08-23 12:53 ` Andrew Cagney 1 sibling, 0 replies; 53+ messages in thread From: Andrew Cagney @ 2002-08-23 12:10 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-23 5:44 ` Daniel Jacobowitz 2002-08-23 12:10 ` Andrew Cagney @ 2002-08-23 12:53 ` Andrew Cagney 2002-08-23 13:15 ` Daniel Jacobowitz 1 sibling, 1 reply; 53+ messages in thread From: Andrew Cagney @ 2002-08-23 12:53 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-23 12:53 ` Andrew Cagney @ 2002-08-23 13:15 ` Daniel Jacobowitz 2002-08-27 21:07 ` Andrew Cagney 0 siblings, 1 reply; 53+ messages in thread From: Daniel Jacobowitz @ 2002-08-23 13:15 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-23 13:15 ` Daniel Jacobowitz @ 2002-08-27 21:07 ` Andrew Cagney 2002-08-28 6:33 ` Daniel Jacobowitz 0 siblings, 1 reply; 53+ messages in thread From: Andrew Cagney @ 2002-08-27 21:07 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 :) :-) ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-27 21:07 ` Andrew Cagney @ 2002-08-28 6:33 ` Daniel Jacobowitz 2002-09-25 8:51 ` Daniel Jacobowitz 2002-09-26 18:39 ` Andrew Cagney 0 siblings, 2 replies; 53+ messages in thread From: Daniel Jacobowitz @ 2002-08-28 6:33 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-28 6:33 ` Daniel Jacobowitz @ 2002-09-25 8:51 ` Daniel Jacobowitz 2002-09-25 11:17 ` Andrew Cagney 2002-09-26 18:39 ` Andrew Cagney 1 sibling, 1 reply; 53+ messages in thread From: Daniel Jacobowitz @ 2002-09-25 8:51 UTC (permalink / raw) To: Andrew Cagney, gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-09-25 8:51 ` Daniel Jacobowitz @ 2002-09-25 11:17 ` Andrew Cagney 0 siblings, 0 replies; 53+ messages in thread From: Andrew Cagney @ 2002-09-25 11:17 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: Andrew Cagney, gdb > > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-08-28 6:33 ` Daniel Jacobowitz 2002-09-25 8:51 ` Daniel Jacobowitz @ 2002-09-26 18:39 ` Andrew Cagney 2002-09-26 18:48 ` Andrew Cagney 2003-06-29 7:51 ` Daniel Jacobowitz 1 sibling, 2 replies; 53+ messages in thread From: Andrew Cagney @ 2002-09-26 18:39 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-09-26 18:39 ` Andrew Cagney @ 2002-09-26 18:48 ` Andrew Cagney 2003-06-29 7:51 ` Daniel Jacobowitz 1 sibling, 0 replies; 53+ messages in thread From: Andrew Cagney @ 2002-09-26 18:48 UTC (permalink / raw) To: gdb > - 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2002-09-26 18:39 ` Andrew Cagney 2002-09-26 18:48 ` Andrew Cagney @ 2003-06-29 7:51 ` Daniel Jacobowitz 2003-09-03 23:41 ` Andrew Cagney 1 sibling, 1 reply; 53+ messages in thread From: Daniel Jacobowitz @ 2003-06-29 7:51 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2003-06-29 7:51 ` Daniel Jacobowitz @ 2003-09-03 23:41 ` Andrew Cagney 2003-09-17 15:51 ` Daniel Jacobowitz 0 siblings, 1 reply; 53+ messages in thread From: Andrew Cagney @ 2003-09-03 23:41 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2003-09-03 23:41 ` Andrew Cagney @ 2003-09-17 15:51 ` Daniel Jacobowitz 2003-09-17 16:19 ` Andrew Cagney 0 siblings, 1 reply; 53+ messages in thread From: Daniel Jacobowitz @ 2003-09-17 15:51 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2003-09-17 15:51 ` Daniel Jacobowitz @ 2003-09-17 16:19 ` Andrew Cagney 2003-09-17 16:23 ` Daniel Jacobowitz 0 siblings, 1 reply; 53+ messages in thread From: Andrew Cagney @ 2003-09-17 16:19 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2003-09-17 16:19 ` Andrew Cagney @ 2003-09-17 16:23 ` Daniel Jacobowitz 2003-09-22 0:27 ` Andrew Cagney 0 siblings, 1 reply; 53+ messages in thread From: Daniel Jacobowitz @ 2003-09-17 16:23 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2003-09-17 16:23 ` Daniel Jacobowitz @ 2003-09-22 0:27 ` Andrew Cagney 2003-09-22 1:01 ` Daniel Jacobowitz 0 siblings, 1 reply; 53+ messages in thread From: Andrew Cagney @ 2003-09-22 0:27 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb > 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2003-09-22 0:27 ` Andrew Cagney @ 2003-09-22 1:01 ` Daniel Jacobowitz 2003-09-22 3:02 ` Andrew Cagney 0 siblings, 1 reply; 53+ messages in thread From: Daniel Jacobowitz @ 2003-09-22 1:01 UTC (permalink / raw) To: Andrew Cagney; +Cc: gdb 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
* Re: RFC: Two small remote protocol extensions 2003-09-22 1:01 ` Daniel Jacobowitz @ 2003-09-22 3:02 ` Andrew Cagney 0 siblings, 0 replies; 53+ messages in thread From: Andrew Cagney @ 2003-09-22 3:02 UTC (permalink / raw) To: Daniel Jacobowitz; +Cc: gdb >> 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 ^ permalink raw reply [flat|nested] 53+ messages in thread
end of thread, other threads:[~2003-09-22 3:02 UTC | newest] Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2002-05-01 19:25 RFC: Two small remote protocol extensions Daniel Jacobowitz 2002-05-02 8:38 ` Andrew Cagney 2002-05-02 8:52 ` Daniel Jacobowitz 2002-05-02 9:39 ` Andrew Cagney 2002-05-02 12:14 ` Daniel Jacobowitz 2002-05-02 12:22 ` Kevin Buettner 2002-05-02 12:34 ` Daniel Jacobowitz 2002-05-02 13:13 ` Andrew Cagney 2002-05-02 14:09 ` Daniel Jacobowitz 2002-05-03 11:24 ` Andrew Cagney 2002-05-03 14:28 ` Daniel Jacobowitz 2002-05-03 15:18 ` Andrew Cagney 2002-05-03 15:22 ` Daniel Jacobowitz 2002-05-04 19:59 ` Andrew Cagney 2002-05-02 13:13 ` Quality Quorum 2002-05-02 14:13 ` Daniel Jacobowitz 2002-05-03 13:07 ` Andrew Cagney 2002-08-16 7:30 ` Daniel Jacobowitz 2002-08-16 7:42 ` Andrew Cagney 2002-08-16 7:52 ` Daniel Jacobowitz 2002-08-16 8:21 ` Andrew Cagney 2002-08-22 19:23 ` Andrew Cagney 2002-08-22 19:36 ` Daniel Jacobowitz 2002-08-23 7:24 ` Quality Quorum 2002-08-23 7:26 ` Daniel Jacobowitz 2002-08-23 7:49 ` Quality Quorum 2002-08-23 8:57 ` Andrew Cagney 2002-08-23 11:16 ` Quality Quorum 2002-08-23 12:39 ` Andrew Cagney 2002-08-23 13:10 ` Quality Quorum 2002-08-27 20:23 ` Andrew Cagney 2002-08-28 8:31 ` Quality Quorum 2002-08-28 9:44 ` Andrew Cagney 2002-08-28 9:49 ` Daniel Jacobowitz 2002-08-22 21:08 ` Andrew Cagney 2002-08-23 5:44 ` Daniel Jacobowitz 2002-08-23 12:10 ` Andrew Cagney 2002-08-23 12:53 ` Andrew Cagney 2002-08-23 13:15 ` Daniel Jacobowitz 2002-08-27 21:07 ` Andrew Cagney 2002-08-28 6:33 ` Daniel Jacobowitz 2002-09-25 8:51 ` Daniel Jacobowitz 2002-09-25 11:17 ` Andrew Cagney 2002-09-26 18:39 ` Andrew Cagney 2002-09-26 18:48 ` Andrew Cagney 2003-06-29 7:51 ` Daniel Jacobowitz 2003-09-03 23:41 ` Andrew Cagney 2003-09-17 15:51 ` Daniel Jacobowitz 2003-09-17 16:19 ` Andrew Cagney 2003-09-17 16:23 ` Daniel Jacobowitz 2003-09-22 0:27 ` Andrew Cagney 2003-09-22 1:01 ` Daniel Jacobowitz 2003-09-22 3:02 ` Andrew Cagney
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).