From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29023 invoked by alias); 12 May 2011 10:45:06 -0000 Received: (qmail 29010 invoked by uid 22791); 12 May 2011 10:45:05 -0000 X-SWARE-Spam-Status: No, hits=-2.7 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-qw0-f41.google.com (HELO mail-qw0-f41.google.com) (209.85.216.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 May 2011 10:44:51 +0000 Received: by qwa26 with SMTP id 26so995381qwa.0 for ; Thu, 12 May 2011 03:44:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.125.134 with SMTP id y6mr35066qar.135.1305197090946; Thu, 12 May 2011 03:44:50 -0700 (PDT) Received: by 10.229.135.145 with HTTP; Thu, 12 May 2011 03:44:50 -0700 (PDT) In-Reply-To: <201105111829.15404.pedro@codesourcery.com> References: <201105101936.55707.pedro@codesourcery.com> <201105111829.15404.pedro@codesourcery.com> Date: Thu, 12 May 2011 10:45:00 -0000 Message-ID: Subject: Re: Stepping of multithreaded application From: Tomas Martinec To: Pedro Alves Cc: gdb@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00048.txt.bz2 >> 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. =A0But 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'. I will implement both the Hc0 and vCont in the virtual machine. But at first I will try to make just the Hc/s/c commands working. > Please try the patch below. =A0It's "any_thread_ptid" that causes "Hc0". > If we're stepping, obviously we need to step the correct thread, not > a random one. =A0I don't really understand how this hasn't been a > problem before. There was another problem after applying the patch. The GDB resumed the thread 1 after the thread 3 stepped. I think I have made a fix: --- infrun_old.c 2010-08-31 21:31:23.000000000 +0200 +++ infrun.c 2011-05-12 12:20:15.000000000 +0200 @@ -3513,6 +3513,8 @@ singlestep_breakpoints_inserted_p =3D 0; } + ecs->event_thread->trap_expected =3D 0; + /* Note: We do not call context_switch at this point, as the context is already set up for stepping the original thread. */ switch_to_thread (deferred_step_ptid); The trap_expected flag of the thread 1 was not cleared after the step of thread 1. Therefore the code has run into the following branch during step handling of the thread 3: infrun.c: line 4182 /* In all-stop mode, if we're currently stepping but have stopped in some other thread, we need to switch back to the stepped thread. */ if (!non_stop) { struct thread_info *tp; tp =3D iterate_over_threads (currently_stepping_or_nexting_callback, ecs->event_thread); if (tp) { // this branch is done, which is wrong; it is done, because the thread 1 // has trap_expected set and therefore the thread is considered to be stepping // // the thread 1 is resumed in this branch; in my case the thread 3 never finishes stepping The debugging seems to be fine after applying my fix. Still I think somebody more familiar with the GDB should review it. Tomas