From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24133 invoked by alias); 11 Jan 2012 19:25:23 -0000 Received: (qmail 24121 invoked by uid 22791); 11 Jan 2012 19:25:22 -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-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Jan 2012 19:25:09 +0000 Received: by vbbfn1 with SMTP id fn1so914769vbb.0 for ; Wed, 11 Jan 2012 11:25:09 -0800 (PST) Received: by 10.52.68.43 with SMTP id s11mr378147vdt.46.1326309909183; Wed, 11 Jan 2012 11:25:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.68.43 with SMTP id s11mr378135vdt.46.1326309909100; Wed, 11 Jan 2012 11:25:09 -0800 (PST) Received: by 10.220.229.1 with HTTP; Wed, 11 Jan 2012 11:25:08 -0800 (PST) In-Reply-To: References: <83r4z8eqoa.fsf@gnu.org> Date: Wed, 11 Jan 2012 19:45:00 -0000 Message-ID: Subject: Re: [PATCH] Add bp_location to Python interface From: Doug Evans To: Kevin Pouget Cc: gdb-patches@sourceware.org, pmuldoon@redhat.com, Eli Zaretskii 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/msg00365.txt.bz2 On Jan 11, 2012 1:02 AM, "Kevin Pouget" wrote: > > I'm not sure we can really move it away from the Python/Guile API, > because, AFAIU, this volatile aspect if purely internal. 'Normal' > users won't ever see it. > > > $ i b > > Num =A0 =A0 Type =A0 =A0 =A0 =A0 =A0 Disp Enb Address =A0 =A0 =A0 =A0 = =A0 =A0What > > 1 =A0 =A0 =A0 breakpoint =A0 =A0 keep y =A0 =A0 > > =A0 =A0 =A0 =A0 1.1 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 y = =A0 =A0 0x4562c0 in main at ../../../git/gdb/gdb/gdb.c:26 inf 2 > > =A0 =A0 =A0 =A0 1.2 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 y = =A0 =A0 0x4562c0 in main at ../../../git/gdb/gdb/gdb.c:26 inf 1 > > will remain the same all the time, but the objects (both in Python and > their GDB backends) in gdb.breakpoints()[0].locations() will be > deleted and re-created at various moments (cf. previous discussions). > So far, I couldn't really understand what's the rational behind that > ... > > [I'm not sure how well you know this part of GDB, please don't > hesitate to correct me if I'm wrong] Yikes, missed that. GDB internals are free to change at will, the python API is the exact oppos= ite. This is the kind of API addition that gives me pause. Once it's in we're stuck. I once wrote a doc on managing GDB features/APIs, loosely based on what I could remember of the SystemV ABI. The ABI elements had three stages in their life, though I don't fully remember the details. IMO, IWBN to have something like it for our Python API. In particular, one could remove something, after a preset amount of time had passed since the announcement of its pending removal. And one could add new things without promising they'll be there forever. That scheme is old, and my memory is sketchy. My point is that today we don't have anything other than: "Once it's in we're stuck." [AFAICT] For the case at hand, IWBN to have some experience with whether this addition works well enough that we want to keep it. And it's not clear we can determine that without some real world use of it.