From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31001 invoked by alias); 11 May 2011 17:29:24 -0000 Received: (qmail 30990 invoked by uid 22791); 11 May 2011 17:29:23 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 May 2011 17:29:07 +0000 Received: (qmail 3845 invoked from network); 11 May 2011 17:29:06 -0000 Received: from unknown (HELO scottsdale.localnet) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 May 2011 17:29:06 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: Stepping of multithreaded application Date: Wed, 11 May 2011 17:29:00 -0000 User-Agent: KMail/1.13.5 (Linux/2.6.35-28-generic; KDE/4.6.2; x86_64; ; ) Cc: Tomas Martinec References: <201105101936.55707.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201105111829.15404.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: 2011-05/txt/msg00044.txt.bz2 On Tuesday 10 May 2011 17:27:20, Tomas Martinec wrote: > From the debugging messages I can see, that the GDB steps twice. The > first step is for the first thread - maybe because the first thread > has just raised the breakpoint. Before the second step the GDB tries > to change the current thread in the virtual machine to 0 (means ANY > according to the doc). Right. > That is not supported in the virtual machine > and the machine responds so. I believe not supporting the Hc0 command > is not wrong for the virtual machine. IMO, it's wrong. But I don't think it'd make a difference, unless the target gives preference to the already/previously selected Hg/c thread. In any case, you should really teach your VM about the vCont packet instead of 'Hc'/'s'/'c'. > Anyway the second step is aimed > for ANY thread and it is applied for the first thread, which both > leads to the unexpected behaviour. I think that the GDB should send > Hc3 command to the simulator before the second step. I think so too. > I have also tried to find out why the Hc3 command is not send from the > GDB sources. The thread id that will be step is determined in resume > function of target.c. In my case the RESUME_ALL ptid is used. That > ptid leads to the Hc0 command. So far I have not understood why the > resume_ptid is kept in the default RESUME_ALL. That's due to the "set scheduler-locking" setting. Even though you're "next"ing thread 3, by default, the other threads run a bit too. See patch below. > -exec-next --thread 3 1 > &"Sending packet: $Hg3#e2..." > &"Ack\n" > &"Packet received: OK\n" > &"Sending packet: $g#67..." > &"Ack\n" > &"Packet received: > 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000200000000000080d8060080000000004c030080040040000000000000000000000000000000000054260080\n" > &"infrun: clear_proceed_status_thread (Thread 3)\n" > &"infrun: clear_proceed_status_thread (Thread 2)\n" > &"infrun: clear_proceed_status_thread (Thread 1)\n" > &"infrun: proceed (addr=0xffffffff, signal=144, step=1)\n" > &"Sending packet: $Hg1#e0..." > &"Ack\n" > &"Packet received: OK\n" > &"Sending packet: $g#67..." > &"Ack\n" > &"Packet received: > 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000080d8040080d804008038030080040040000000000000000000000000000000000040250080\n" > &"Sending packet: $g#67..." > &"Ack\n" > &"Packet received: > 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000000000000000080d8040080d804008038030080040040000000000000000000000000000000000040250080\n" > &"infrun: resume (step=1, signal=0), trap_expected=1\n" > &"Sending packet: $Hc1#dc..." > &"Ack\n" > &"Packet received: OK\n" > &"Sending packet: $s#73..." We want to "next" thread 3 (which resumes all other threads as well, see the manual for "set scheduler-locking"), but thread 1 was stopped at a breakpoint, so we need to move it past the breakpoint first (infrun.c:prepare_to_proceed). > &"Ack\n" > ^running > *running,thread-id="1" > (gdb) > &"infrun: wait_for_inferior (treat_exec_as_sigtrap=0)\n" > &"Packet received: T05thread:00000001;25:44250080;\n" > &"infrun: target_wait (-1, status) =\ninfrun: 42000 [Thread > 1],\ninfrun: status->kind = stopped, signal = SIGTRAP\n" > &"infrun: infwait_normal_state\n" > &"infrun: TARGET_WAITKIND_STOPPED\n" > &"infrun: stop_pc = 0x80002544\n" > &"infrun: handling deferred step\n" Done. Go back to stepping thread 3 and resuming all others... > &"Sending packet: $Hg3#e2..." > &"Ack\n" > &"Packet received: OK\n" > &"Sending packet: $g#67..." > &"Ack\n" > &"Packet received: > 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000100000200000000000080d8060080000000004c030080040040000000000000000000000000000000000058260080\n" > &"infrun: resume (step=1, signal=0), trap_expected=0\n" > &"Sending packet: $Hc0#db..." Select any thread in the target... (Indeed strange.) > &"Ack\n" > &"Packet received: \n" > &"Sending packet: $s#73..." Step the target... > &"Ack\n" > *running,thread-id="all" > &"infrun: prepare_to_wait\n" > &"Packet received: T05thread:00000001;25:48250080;\n" The target finished stepping thread 1. But we wanted thread 3 to be stepped... Please try the patch below. It's "any_thread_ptid" that causes "Hc0". If we're stepping, obviously we need to step the correct thread, not a random one. I don't really understand how this hasn't been a problem before. As explained above and in the comment in the patch, you should really teach your target to support the vCont packet. Hc/s are deprecated for multi-threading. Pedro Alves 2011-05-11 Pedro Alves gdb/ * remote.c (remote_resume): Set the continue thread to inferior_ptid if the core passed in a wildcard resume, instead of setting it to a random thread. --- gdb/remote.c | 13 +++++++++++-- 1 file changed, 11 insertions(+), 2 deletions(-) Index: src/gdb/remote.c =================================================================== --- src.orig/gdb/remote.c 2011-05-11 15:17:48.658167999 +0100 +++ src/gdb/remote.c 2011-05-11 18:00:13.988168000 +0100 @@ -4542,8 +4542,17 @@ remote_resume (struct target_ops *ops, /* All other supported resume packets do use Hc, so set the continue thread. */ - if (ptid_equal (ptid, minus_one_ptid)) - set_continue_thread (any_thread_ptid); + + /* A wildcard PTID means either "step the current thread and + continue others", or "continue all threads". + + A specific PTID means `step only this process id'. Problem is + the 's' packet is ambiguous: "step just this thread and leave + others stopped", or "step this thread and continue all others"? + vCont doesn't have this problem. */ + + if (ptid_equal (minus_one_ptid, ptid) || ptid_is_pid (ptid)) + set_continue_thread (inferior_ptid); else set_continue_thread (ptid);