Re: Behaviour of default all-stop mode -- Why no one has replied ?

[Pedro Alves <pedro at codesourcery dot com>]

> On Wednesday 10 June 2009 08:18:19, suresh ds wrote:
> Re: Behaviour of default all-stop mode -- Why no one has replied ?

Because we're all volunteers and busy people here.

On Wednesday 10 June 2009 08:18:19, suresh ds wrote:
> I'm re-posting my previous query. 

Replying to the other query would be better, in terms
of preserving answers close to the questions, so that
other people googling around with the same problem have
better chances of finding them.

> The foll. are w.r.to remote debugging in gdb 6.8 cross-compiled for mips64.
> 
> In the default all-stop mode,

Non-stop mode was only added post 6.8, so, this is about how GDB
has behaved since ever.

> 
> 1) The document says, "whenever your program stops under GDB for any reason,all threads of execution stop, not just the current thread"
> -- Here, the initiation is done by gdb or the (remote) stub should take care of this ?

The stub.

> Suppose three threads are running, say 1, 2, & 3.
> Suppose thread 1 hits the breakpoint; It'll send the status to gdb; At this point, gdb itself will send (further) packets to stop other threads, or the stub itself should take the initiative to stop other threads ?

The stub.

> 2) The document says, "whenever you restart the program, all threads start executing".
> -- Again, the gdb takes initiative to continue all the threads or the stub should have a mechanism to do this ?
> Suppose three threads, 1, 2, & 3 are in a stopped state.

See the vCont packet description.  That packet explicitly says what to resume,
there's no all-stop vs non-stop magic in that aspect.

> Now, "continue" from thread 1 will continue all the threads ?
> When I checked the packets, I found that it does only "Hc1" to set the further continue packets only for thread 1.

Implement vCont support instead, s,c,Hc are deprecated for multithreaded stubs.

> The document does not clearly explain whether the initiative, to stop all the threads once a thread hits a break and to continue all the threads if a continue is given from a thread, is the responsibility of gdb or stub, and how. And an inspection of gdb's packets sent to stub throw no light either.

I suggest studying the trafic between gdb and gdbserver.


I did find this in "D.10 Remote Protocol Support for Non-Stop Mode":

 "(...) In contrast to all-stop mode, where all threads in all processes
  are stopped when a stop reply is sent, in non-stop mode only the thread reporting the
  stop event is stopped.  (...)",

you can infer the all-stop behaviour from this, but, I agree with you that
it would be nice to clarify these points closer to the packet descriptions.

-- 
Pedro Alves