From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108524 invoked by alias); 22 Apr 2015 20:03:15 -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 108505 invoked by uid 89); 22 Apr 2015 20:03:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 22 Apr 2015 20:03:14 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id CD46D2BB3BF; Wed, 22 Apr 2015 20:03:12 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t3MK3B26009192; Wed, 22 Apr 2015 16:03:11 -0400 Message-ID: <5537FE7F.8050007@redhat.com> Date: Wed, 22 Apr 2015 20:03:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Yao Qi 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> <86tww9y18h.fsf@gmail.com> In-Reply-To: <86tww9y18h.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-04/txt/msg00840.txt.bz2 On 04/21/2015 04:01 PM, Yao Qi wrote: > Pedro Alves writes: > >> - that adjust_pc_after_break doesn't end up confused. */ >> - gdb_assert (sig != 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 Yep. In that case, we should _not_ step over the breakpoint, as thread B has not reported that breakpoint event. Detecting the case and reporting the breakpoint immediately without actually resuming isn't correct, as in that case we'd lose the signal. It's just simpler to let the breakpoint trap. > >> >> +/* 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? > I think so, yes. Though I'd rather leave it be for a while, so that the "maint set target-non-stop off" fallback option is fully functional as backup plan. In the long term, if we manage to merge linux-nat.c and gdbserver/linux-low.c, the resulting code will still need it as long as we'd like to support gdbserver connected to a gdb that doesn't force non-stop mode though, and, probably as long as gdbserver's own step-over-breakpoints/tracepoints implementation is baked in the backend too. :-/ Thanks, Pedro Alves