From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126808 invoked by alias); 21 Apr 2015 15:01:26 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 126793 invoked by uid 89); 21 Apr 2015 15:01:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pa0-f54.google.com Received: from mail-pa0-f54.google.com (HELO mail-pa0-f54.google.com) (209.85.220.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 21 Apr 2015 15:01:24 +0000 Received: by pabtp1 with SMTP id tp1so243446550pab.2 for ; Tue, 21 Apr 2015 08:01:22 -0700 (PDT) X-Received: by 10.66.251.165 with SMTP id zl5mr38156190pac.93.1429628482051; Tue, 21 Apr 2015 08:01:22 -0700 (PDT) Received: from E107787-LIN (gcc1-power7.osuosl.org. [140.211.15.137]) by mx.google.com with ESMTPSA id l1sm64773pdp.71.2015.04.21.08.01.19 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 21 Apr 2015 08:01:20 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v3 09/17] Teach non-stop to do in-line step-overs (stop all, step, restart) References: <1429267521-21047-1-git-send-email-palves@redhat.com> <1429267521-21047-10-git-send-email-palves@redhat.com> Date: Tue, 21 Apr 2015 15:01:00 -0000 In-Reply-To: <1429267521-21047-10-git-send-email-palves@redhat.com> (Pedro Alves's message of "Fri, 17 Apr 2015 11:45:13 +0100") Message-ID: <86tww9y18h.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00766.txt.bz2 Pedro Alves writes: > - that adjust_pc_after_break doesn't end up confused. */ > - gdb_assert (sig !=3D GDB_SIGNAL_0); > + that adjust_pc_after_break doesn't end up confused. > + > + - In non-stop if we insert a breakpoint (e.g., a step-resume) > + in one thread after another thread that was stepping had been > + momentarily paused for a step-over. When we re-resume the > + stepping thread, it may be resumed from that address with a > + breakpoint that hasn't trapped yet. Seen with > + gdb.threads/non-stop-fair-events.exp, on targets that don't > + do displaced stepping. */ Does this comment mean the sequence like this? thread B is paused, a breakpoint is inserted at address PC for thread C, thread B may be resumed from address PC >=20=20 > +/* Select a thread at random, out of those which are resumed and have > + had events. */ > + > +static struct thread_info * > +random_pending_event_thread (ptid_t waiton_ptid) > +{ If GDB core knows select events at random, then we don't have to do something similar in linux-nat.c:select_event_lwp, right? --=20 Yao (=E9=BD=90=E5=B0=A7)