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

["suresh ds" <dssuresh66 at mail dot com>]

Thanks for the reply. I've some more queries, interspersed with ==>>

Regards,
Suresh


----- Original Message -----
From: "Pedro Alves" 
To: gdb@sourceware.org
Cc: "suresh ds" 
Subject: Re: Behaviour of default all-stop mode -- Why no one has replied ?
Date: Wed, 10 Jun 2009 18:56:12 +0100


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

==>> So, the stub take the initiative to stop other threads. In this case, the other threads' status should also be reported to gdb ?


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

==>> But I get indication from gdb only to start one thread; Maybe, this will change if the stub reports the status of all the threads initially ??


> 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 tried debugging a pthread program through gdbserver on intel-i386. But info threads was not recognizing the threads; I don't know if I should compile/configure gdbserver separately for thread mode ...


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


-- 
Be Yourself @ mail.com!
Choose From 200+ Email Addresses
Get a Free Account at www.mail.com