From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26738 invoked by alias); 15 Jun 2009 18:44:43 -0000 Received: (qmail 26729 invoked by uid 22791); 15 Jun 2009 18:44:42 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_51,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; Mon, 15 Jun 2009 18:44:37 +0000 Received: (qmail 32395 invoked from network); 15 Jun 2009 18:44:35 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 15 Jun 2009 18:44:35 -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 18:44:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb@sourceware.org References: <20090615150945.0332EBE407F@ws1-9.us4.outblaze.com> In-Reply-To: <20090615150945.0332EBE407F@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: <200906151945.05325.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/msg00157.txt.bz2 On Monday 15 June 2009 16:09:44, suresh ds wrote: > Packet received: T05thread:4;thread:5;thread:6; I have a feeling that GDB will parse this and end up ignoring the "thread4;thread5" part, as thread:6 will clobber whatever was parsed as thread id before. Implementing a stub means to pass to GDB what GDB wants to, not what you might think you should pass. Here, you want only "T05thread:4", that's it. In all-stop mode, events have to be serialized to GDB, so, it doesn't really make sense to pass more than one status. > > ==>> Well, the stub sitting on thread 4 (default hardware thread) corresponds to gdb here. It also sends the status of other (hardware) threads. Initially, I made thread 4 pass only its status as "$T05thread:4", but no difference. > > Sending packet: $Hc-1#09...Ack > > ==>> Here, gdb asks to resume all threads, '-1' indicating 'all threads'. But I don't resume here, all the threads are still in stopped state. If I resume all the threads here in fact, I don't think it'll matter ? Sure it does matter. You're resuming the target when GDB has *not* told you to. 'H' is, and I quote: "Set thread for subsequent operations". It just selects the threads, doesn't resume them. In any case, if you implement vCont, you won't see GDB sending Hc appart from this initial one. You can safely ignore this, as the vCont packet is stateless. > ==>> The stub on ht4 (hardware thread 4), has reported three threads, 4, 5, and 6 to gdb; And, gdb has switched to the last reported thread here. Right, in all-stop mode, GDB always switches the general thread to to the thread that reported the event, and (this is important) assumes that the stub has also switched the general thread accordingly. > ==>> At this point, gdb is made aware that there are three threads waiting to be debugged; > Already, the presence of these threads were also indicated when the stub on the default thread sent the status of all the threads. Well, you think it has, but it hasn't. Those extra statuses are just ignored. > > (rmios-gdb)c > Continuing. > Sending packet: $vCont?#49...Ack > Packet received: vCont;c;C;s;S;t;T > Packet vCont (verbose-resume) is supported > Sending packet: $vCont;c#a8...Ack > > ==>> In default all-stop mode, when you do continue, all threads should continue, correct ? According to our discussions so far (read mails below), gdb will indicate through vCont, which threads it wants to resume. But here, it does not indicate. So, which thread should I resume ? Actually, I resumed the default thread (4). Should the stub resume all the threads even though it has not received any thread no. ? I already pointed out what should happen here. Pasting again: > `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; > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > So, "vCont;c" reads: action == 'c'ontinue; no thread-id specified, and no other threads have a specific action specified --> means that action "continue" is applied to all threads. In other words: vCont;c --> continue all threads vCont;c:1 --> continue just thread 1 vCont;s:1;c --> step thread 1, continue all others vCont;s:1 --> step thread 1, leaving all others stopped. > > Now, this is without any breakpoints set. Even if I set a breakpoint and continue, it only continues the 'current' thread. I typically expect something like this from gdb. "$vCont;c:4;c:5;blahblah". How can you "typically" expect something from the protocol you're just learning is mystifying to me. ;-) > After thread 4 hits the breakpoint, then I switch to some other thread,say 5, and continue, gdb still sends packets only to continue thread 4; Thread 5 does not move at all. In other words, switching to any thread does not make gdb to send packets in that thread context (which I've complained earlier). > > I tried 'thread-specific breakpoints', and 'thread apply', but to no avail. Forget breakpoint setting; First of all, when I continue from one thread, why gdb is not issuing packets to resume all the threads? Is this not the expected behaviour in default all-stop mode ? In our earlier discussions, you have mentioned that that stub itself should not resume all the threads and that the gdb will indicate that through vCont packets, which is not happening here. It is. You have to learn about the "(gdb) set scheduler-locking" setting first to understand what GDB wants to resume by default. (you also have the sources of GDB at your disposal. You can make use of it to your advantage! src/gdb/remote.c is where all the remote protocol action happens). -- Pedro Alves