From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13131 invoked by alias); 10 Jan 2012 22:19:15 -0000 Received: (qmail 13122 invoked by uid 22791); 10 Jan 2012 22:19:13 -0000 X-SWARE-Spam-Status: No, hits=-3.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_LOW,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-vx0-f169.google.com (HELO mail-vx0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 10 Jan 2012 22:19:00 +0000 Received: by vcge1 with SMTP id e1so75962vcg.0 for ; Tue, 10 Jan 2012 14:19:00 -0800 (PST) Received: by 10.221.13.2 with SMTP id pk2mr1299729vcb.71.1326233939981; Tue, 10 Jan 2012 14:18:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.221.13.2 with SMTP id pk2mr1299719vcb.71.1326233939865; Tue, 10 Jan 2012 14:18:59 -0800 (PST) Received: by 10.220.229.1 with HTTP; Tue, 10 Jan 2012 14:18:59 -0800 (PST) In-Reply-To: References: <83r4z8eqoa.fsf@gnu.org> Date: Tue, 10 Jan 2012 22:24:00 -0000 Message-ID: Subject: Re: [PATCH] Add bp_location to Python interface From: Doug Evans To: Kevin Pouget Cc: Eli Zaretskii , gdb-patches@sourceware.org, pmuldoon@redhat.com X-System-Of-Record: true Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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: 2012-01/txt/msg00328.txt.bz2 On Tue, Jan 10, 2012 at 6:50 AM, Kevin Pouget wrot= e: >>> +@defun BpLocation.is_valid () >>> +Returns @code{True} if the @code{gdb.BpLocation} object is valid, >>> +@code{False} if not. =A0A @code{gdb.BpLocation} object may be invalida= ted by >>> +GDB at any moment for internal reasons. =A0All other @code{gdb.BpLocat= ion} >>> +methods and attributes will throw an exception if the object is invali= d. >> >> @value{GDBN} instead of "GDB". >> >> In any case, the last 2 sentences sound scary: I could interpret them >> as meaning I cannot trust the locations at all. =A0If that is indeed so, >> what use are they? > > that's already discussed above, but I don't want you to be scared, so > let me explain what I meant: > it's not "at any moment", but rather "after any call to GDB's Python > interface". We may want to say that it's only breakpoint or > execution-related calls, but _I_ can't ensure that this is true, and > it 'might' change in the future: > >> A @code{gdb.BpLocation} object may be invalidated during >> any call to @{GDB}'s API for internal reasons (for instance, but not lim= ited to, >> breakpoint or execution-related mechanisms). > > (I'm not sure what's the right Python term here for 'mechanisms', > reading/writing an attribute may trigger internal functions, so 'call' > or 'function' seem not to suit very well) Don't take this as a requirement, but this volatility isn't a property of python's BpLocations, Thus I'd rather see the general discussion of why breakpoint locations are volatile, scary, whatever, elsewhere, and just have a link to that documentation here. I think that will help clear things up: In the breakpoints section of the manual just state what breakpoint locations are, what their properties are, etc. Then in the above docs you don't have to worry so much about scaryness or whatever: Whatever issues locations have, users already need to be at least somewhat aware of them. Another reason to do this is that when Guile scripting gets added, we don't want to have to document these issues twice. :-)