From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31581 invoked by alias); 26 Mar 2008 20:04:07 -0000 Received: (qmail 31571 invoked by uid 22791); 26 Mar 2008 20:04:03 -0000 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 26 Mar 2008 20:03:37 +0000 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw1.br.ibm.com (Postfix) with ESMTP id 836A532C04D for ; Wed, 26 Mar 2008 16:42:10 -0300 (BRST) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m2QK2t1o3534872 for ; Wed, 26 Mar 2008 17:03:19 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m2QK2s8o031648 for ; Wed, 26 Mar 2008 17:02:54 -0300 Received: from [9.18.238.95] ([9.18.238.95]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m2QK2sHe031645; Wed, 26 Mar 2008 17:02:54 -0300 Subject: Re: repo to work on python scripting support From: Thiago Jung Bauermann To: Tom Tromey Cc: Doug Evans , gdb ml In-Reply-To: References: <1205538908.6643.138.camel@localhost.localdomain> <1206369478.29533.15.camel@localhost.localdomain> <20080326180455.GA22644@caradoc.them.org> <20080326182505.GA2816@caradoc.them.org> Content-Type: text/plain Date: Wed, 26 Mar 2008 21:01:00 -0000 Message-Id: <1206561774.29533.68.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00250.txt.bz2 On Wed, 2008-03-26 at 11:44 -0600, Tom Tromey wrote: > Long-term compatibility in the Python API is something we haven't > discussed. I'm really not sure what to do about this -- we really are > exposing a decent amount of gdb internals to the world this way. We are, but at least up until now we've been exposing things which are there in GDB for a long time now (struct breakpoint, struct frame_info, struct value), and attributes which are fairly intrinsic to them, like frame.get_pc(). I expect this stuff to be stable between releases. I also expect that most (if not all) of what is exposed is along these lines, that is, providing a "view" of the general GDB internal components, as oposed to exposing exoteric internal GDB code which is likely to change often. Since the C <-> Python glue code provide some decoupling, it's possible to accomodate for some changes in the GDB internals. All in all, my hope is that compatibility of python scripts accross GDB versions won't be a frequent issue. We could provide a method which returns the GDB versions so that scripts can accomodate for changes, if the need arises? -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center