From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1459 invoked by alias); 7 Jan 2015 07:06:10 -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 1440 invoked by uid 89); 7 Jan 2015 07:06:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Jan 2015 07:06:05 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1Y8kgr-00033o-Nc from Yao_Qi@mentor.com ; Tue, 06 Jan 2015 23:06:01 -0800 Received: from GreenOnly (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.3.224.2; Tue, 6 Jan 2015 23:06:01 -0800 From: Yao Qi To: Pedro Alves CC: Subject: Re: [PATCH 6/8] linux-nat.c: better starvation avoidance, handle non-stop mode too References: <1419625871-28848-1-git-send-email-palves@redhat.com> <1419625871-28848-7-git-send-email-palves@redhat.com> Date: Wed, 07 Jan 2015 07:06:00 -0000 In-Reply-To: <1419625871-28848-7-git-send-email-palves@redhat.com> (Pedro Alves's message of "Fri, 26 Dec 2014 20:31:09 +0000") Message-ID: <8761cjul2b.fsf@codesourcery.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-01/txt/msg00095.txt.bz2 Pedro Alves writes: > 3) If multiple threads hit a breakpoint, we report one of those, and > "cancel" the others. Cancelling means decrementing the PC, and > discarding the event. If the next time the LWP is resumed the > breakpoint is still installed, the LWP should hit it again, and we'll > report the hit then. The problem I found is that this delays threads > from advancing too much, with the kernel potentially ending up > scheduling the same threads over and over, and others not advancing. Sorry, I don't fully understand what is the problem. Can you elaborate? Is it something like GDB gets an event of thread foo, and events from other threads aren't interesting. GDB cancels them, but when GDB resumes them, kernel always schedules thread foo. > So the patch switches away from cancelling the breakpoints, and > instead remembering that the LWP had stopped for a breakpoint. If on > resume the breakpoint is still installed, we report it. If it's no > longer installed, we discard the pending event then. This is actually Does "breakpoint is installed" indicate "target is still running"? then, we report the event. Otherwise, "target is stopped", we discard the pending event. Is that correct? > @@ -2453,7 +2482,9 @@ stop_wait_callback (struct lwp_info *lp, void *data) > return 0; > } >=20=20 > -/* Return non-zero if LP has a wait status pending. */ > +/* Return non-zero if LP has a wait status pending. Discard the > + pending event and resume the LWP if the event that originally > + caused the stop became uninteresting. */ >=20=20 > static int > status_callback (struct lwp_info *lp, void *data) Probably, we should rename status_callback to something more meaningful. > @@ -2523,16 +2601,19 @@ select_event_lwp_callback (struct lwp_info *lp, v= oid *data) >=20=20 > gdb_assert (selector !=3D NULL); >=20=20 > - /* Select only resumed LWPs that have a SIGTRAP event pending. */ > - if (lp->resumed && linux_nat_lp_status_is_event (lp)) > + /* Select only resumed LWPs that have an event pending. */ > + if (lp->resumed && lwp_status_pending_p (lp)) > if ((*selector)-- =3D=3D 0) > return 1; Do we need to do the same change in count_events_callback? IMO, the condition in both count_events_callback and select_event_lwp_callback should be consistent. --=20 Yao (=E9=BD=90=E5=B0=A7)