From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17432 invoked by alias); 15 Jun 2009 11:01:26 -0000 Received: (qmail 17260 invoked by uid 22791); 15 Jun 2009 11:01:25 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,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; Mon, 15 Jun 2009 11:01:19 +0000 Received: (qmail 15253 invoked from network); 15 Jun 2009 11:01:16 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Jun 2009 11:01:16 -0000 From: Pedro Alves To: "suresh ds" Subject: Re: Behaviour of default all-stop mode -- Why no one has replied ? Date: Mon, 15 Jun 2009 11:01:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb@sourceware.org References: <20090615103753.DD1EDBE407F@ws1-9.us4.outblaze.com> In-Reply-To: <20090615103753.DD1EDBE407F@ws1-9.us4.outblaze.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906151201.44356.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/msg00139.txt.bz2 On Monday 15 June 2009 11:37:53, suresh ds wrote: > > 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 ? Nope. The other threads are supposedly stopped without anything interesting to report to GDB. Only one event is reported to GDB at a time. If while your stub tries to stop all threads to report a stop event to GDB (e.g., breakpoint hits in thread 1), one of those threads hits another event (e.g., thread 2 gets signal) then you have to deal with it. E.g., leaving the extra events pending until the next time GDB tells the threads to resume, or, by tweaking the thread state so that the event would naturally trigger again the next time you resume the threads. If your stub is in-kernel, assuming one core only, then usually you don't have to care for these complications, as all threads are halted while the stub's code is executing. > > > > 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 ?? I think you're not reading the packet right, but this this is just guessing, since now at this point, I don't know if you're talking about vCont or c or s... Please be specific. `vCont[;action[:thread-id]]...' Resume the inferior, specifying different actions for each thread. If an action is specified with no thread-id, then it is applied to any ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ threads that don't have a specific action specified; ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > 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 ... It should just work, if you run gdbserver on the same machine as gdb. Otherwise, you may be stumbling on point 6 at http://sourceware.org/gdb/wiki/FAQ. -- Pedro Alves