From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4024 invoked by alias); 17 Sep 2014 13:16:43 -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 4013 invoked by uid 89); 17 Sep 2014 13:16:42 -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 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, 17 Sep 2014 13:16:41 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1XUF65-0002N1-VG from Yao_Qi@mentor.com ; Wed, 17 Sep 2014 06:16:37 -0700 Received: from GreenOnly (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.3.181.6; Wed, 17 Sep 2014 06:16:37 -0700 From: Yao Qi To: Pedro Alves CC: Subject: Re: [PATCH/DOC RFA] Fix "breakpoint always-inserted off"; remove "breakpoint always-inserted auto" References: <1410913576-4928-1-git-send-email-palves@redhat.com> Date: Wed, 17 Sep 2014 13:16:00 -0000 In-Reply-To: <1410913576-4928-1-git-send-email-palves@redhat.com> (Pedro Alves's message of "Wed, 17 Sep 2014 01:26:16 +0100") Message-ID: <8738bq1jcz.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: 2014-09/txt/msg00585.txt.bz2 Pedro Alves writes: > In hindsight, this "auto" setting was unnecessary, and not the ideal > solution. Non-stop mode does depends on breakpoints always-inserted > mode, but only as long as any thread is running. If no thread is > running, no breakpoint can be missed. The same is true for all-stop > too. E.g., if, in all-stop mode, and the user does: > > (gdb) c& > (gdb) b foo > > That breakpoint at "foo" should be inserted immediately, but it > currently isn't -- currently it'll end up inserted only if the target > happens to trip on some event, and is re-resumed, e.g., an internal > breakpoint triggers that doesn't cause a user-visible stop, and so we > end up in keep_going calling insert_breakpoints. > > IOW, no matter whether in non-stop or all-stop, if the target fully > stops, we can remove breakpoints. And no matter whether in all-stop > or non-stop, if any thread is running in the target, then we need > breakpoints to be immediately inserted. And then, if the target has Could we add some test cases for this? for example, breakpoint should be inserted immediately if any thread is running. > +/* update_global_location_list's modes of operation wrt to whether to > + insert locations now. */ > +enum ugll_insert_mode > +{ > + /* Don't insert any breakpoint locations into the inferior, only > + remove already-inserted locations that no longer should be > + inserted. Functions that delete a breakpoint or breakpoints > + should specify this mode, so that deleting a breakpoint doesn't > + have the side effect of inserting the locations of other > + breakpoints that are marked not-inserted, but should_be_inserted > + returns true on them. > + > + This behavior is useful is situations close to tear-down -- e.g., > + after an exec, while the target still has execution, but > + breakpoint shadows of the previous executable image should *NOT* > + be restored to the new image; or before detaching, where the > + target still has execution and wants to delete breakpoints from > + GDB's lists, and all breakpoints had already been removed from > + the inferior. */ > + UGLL_DONT_INSERT, > + > + /* May insert breakpoints iff breakpoints_should_be_inserted_now > + claims breakpoints should be inserted now. */ > + UGLL_MAY_INSERT, > + > + /* Insert locations now, even if breakpoints_should_be_inserted_now > + would return false. For example, no thread is resumed yet, but > + we're just about to resume the target. */ > + UGLL_INSERT, > +}; > + What does the last sentence in comments mean? "no thread is resumed yet, but we're just about to resume the target." The patch looks good to me. However, IWBN to split it to two, patch 1 is about refactor update_global_location_list and add enum ugll_insert_mode with only UGLL_DONT_INSERT and UGLL_MAY_INSERT. patch 2 does the rest. --=20 Yao (=E9=BD=90=E5=B0=A7)