From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6818 invoked by alias); 10 Jun 2009 17:55:22 -0000 Received: (qmail 6809 invoked by uid 22791); 10 Jun 2009 17:55:21 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_63,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Jun 2009 17:55:13 +0000 Received: (qmail 19323 invoked from network); 10 Jun 2009 17:55:08 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 10 Jun 2009 17:55:08 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: Behaviour of default all-stop mode -- Why no one has replied ? Date: Wed, 10 Jun 2009 17:55:00 -0000 User-Agent: KMail/1.9.10 Cc: "suresh ds" References: <20090610071819.04F30606884@ws1-4.us4.outblaze.com> In-Reply-To: <20090610071819.04F30606884@ws1-4.us4.outblaze.com> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200906101856.12518.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-06/txt/msg00091.txt.bz2 > 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