From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24427 invoked by alias); 6 Oct 2011 13:58:49 -0000 Received: (qmail 24412 invoked by uid 22791); 6 Oct 2011 13:58:47 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 06 Oct 2011 13:58:34 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p96DwThX026925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 6 Oct 2011 09:58:29 -0400 Received: from localhost.localdomain (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p96DwRgF001280; Thu, 6 Oct 2011 09:58:28 -0400 From: Phil Muldoon To: Pedro Alves Cc: gdb-patches@sourceware.org, eli@gnu.org Subject: Re: [python] [doc] PR 12930/12802 (clarify Breakpoint::stop doco) References: <201110061439.46304.pedro@codesourcery.com> Reply-to: pmuldoon@redhat.com X-URL: http://www.redhat.com Date: Thu, 06 Oct 2011 13:58:00 -0000 In-Reply-To: <201110061439.46304.pedro@codesourcery.com> (Pedro Alves's message of "Thu, 6 Oct 2011 14:39:46 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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 X-SW-Source: 2011-10/txt/msg00158.txt.bz2 Pedro Alves writes: > On Thursday 06 October 2011 11:58:51, Phil Muldoon wrote: >> >> This patch address the PRs 12930, and 12802 which both arise from >> confusion regarding the scope of actions in the Breakpoint::stop >> callback. I have added some documentation to clarify. >> >> Pedro, please excuse the gratuitous CC, but beyond Eli's normal review >> can you please fact-check the documentation to make sure I am not >> writing something about states that is incorrect. > > Thanks! Looks good fact-wise. I think infcalls will make sense to call here > (we do support them in the normal breakpoint condition), but that > supposedly doesn't leave the inferior's state unaltered, so we're good. > > I could be made possible to self delete a breakpoint in the callback, > but that's not the current state of affairs, it seems. I'm not opposed to allowing the user to delete, but my view is that "stop" should make decisions, and not alter state. OTOH, I'm not strongly moved other than personal preferences, so I can remove that line if need be. Cheers, Phil