From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1250 invoked by alias); 15 Jun 2009 10:38:03 -0000 Received: (qmail 1231 invoked by uid 22791); 15 Jun 2009 10:38:02 -0000 X-SWARE-Spam-Status: No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_63 X-Spam-Check-By: sourceware.org Received: from outbound1-1.us4.outblaze.com (HELO outbound1-1.us4.outblaze.com) (208.36.123.129) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 15 Jun 2009 10:37:56 +0000 Received: from wfilter3.us4.outblaze.com.int (wfilter3.us4.outblaze.com.int [192.168.8.242]) by outbound1-1.us4.outblaze.com (Postfix) with QMQP id 8CAD87A1354 for ; Mon, 15 Jun 2009 10:37:54 +0000 (GMT) X-OB-Received: from unknown (208.36.123.73) by wfilter3.us4.outblaze.com; 15 Jun 2009 10:37:54 -0000 Received: by ws1-9.us4.outblaze.com (Postfix, from userid 1001) id DD1EDBE407F; Mon, 15 Jun 2009 10:37:53 +0000 (GMT) Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 From: "suresh ds" To: "Pedro Alves" Cc: gdb@sourceware.org Date: Mon, 15 Jun 2009 10:38:00 -0000 Subject: Re: Behaviour of default all-stop mode -- Why no one has replied ? Received: from [203.92.57.132] by ws1-9.us4.outblaze.com with http for dssuresh66@mail.com; Mon, 15 Jun 2009 05:37:53 -0500 X-Ob-Auth: dssuresh66:mail.com@mail.com Message-Id: <20090615103753.DD1EDBE407F@ws1-9.us4.outblaze.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/msg00138.txt.bz2 Thanks for the reply. I've some more queries, interspersed with =3D=3D>> Regards, Suresh ----- Original Message ----- From: "Pedro Alves"=20 To: gdb@sourceware.org Cc: "suresh ds"=20 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 mips6= 4. > > 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=20 > any reason,all threads of execution stop, not just the current=20 > thread" > -- Here, the initiation is done by gdb or the (remote) stub=20 > 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=20 > gdb; At this point, gdb itself will send (further) packets to=20 > stop other threads, or the stub itself should take the initiative=20 > to stop other threads ? The stub. =3D=3D>> So, the stub take the initiative to stop other threads. In this ca= se, the other threads' status should also be reported to gdb ? > 2) The document says, "whenever you restart the program, all=20 > threads start executing". > -- Again, the gdb takes initiative to continue all the threads or=20 > 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 resu= me, 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=20 > set the further continue packets only for thread 1. Implement vCont support instead, s,c,Hc are deprecated for=20 multithreaded stubs. =3D=3D>> But I get indication from gdb only to start one thread; Maybe, thi= s will change if the stub reports the status of all the threads initially ?? > The document does not clearly explain whether the initiative, to=20 > stop all the threads once a thread hits a break and to continue=20 > all the threads if a continue is given from a thread, is the=20 > responsibility of gdb or stub, and how. And an inspection of=20 > gdb's packets sent to stub throw no light either. I suggest studying the trafic between gdb and gdbserver. =3D=3D>> I tried debugging a pthread program through gdbserver on intel-i38= 6. But info threads was not recognizing the threads; I don't know if I shou= ld 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=20 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 --=20 Be Yourself @ mail.com! Choose From 200+ Email Addresses Get a Free Account at www.mail.com