From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11213 invoked by alias); 27 Apr 2012 15:37:22 -0000 Received: (qmail 11204 invoked by uid 22791); 27 Apr 2012 15:37:21 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout21.012.net.il (HELO mtaout21.012.net.il) (80.179.55.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Apr 2012 15:37:07 +0000 Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0M3500G00A06HY00@a-mtaout21.012.net.il> for gdb-patches@sourceware.org; Fri, 27 Apr 2012 18:36:51 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.229.249.186]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M3500GX2A1EG920@a-mtaout21.012.net.il>; Fri, 27 Apr 2012 18:36:51 +0300 (IDT) Date: Fri, 27 Apr 2012 15:38:00 -0000 From: Eli Zaretskii Subject: Re: [RFC - doc] Add note about the possibility of symbols getting moved across blocks In-reply-to: To: Siva Chandra Cc: tromey@redhat.com, dje@google.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83pqatgp9k.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT References: <83bomgfcbt.fsf@gnu.org> <87ipgna94k.fsf@fleche.redhat.com> <83y5pjedjp.fsf@gnu.org> <87397qa9a0.fsf@fleche.redhat.com> <83fwbqinsw.fsf@gnu.org> 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-04/txt/msg00999.txt.bz2 > Date: Fri, 27 Apr 2012 16:33:06 +0530 > From: Siva Chandra > Cc: Tom Tromey , Doug Evans , gdb-patches@sourceware.org > > On Thu, Apr 26, 2012 at 7:43 PM, Eli Zaretskii wrote: > > Maybe I simply miss something important here.  The text in question > > says this: > > > >   A @code{gdb.Block} is iterable.  The iterator returns the symbols > >   (@pxref{Symbols In Python}) local to the block.  Users using this > >   feature should keep in mind that future improvements to the internal > >   representation, of symbols and symbol tables, can move symbols across > >   blocks within a symbol table. > > > > Are you saying that future changes will prevent the possibility to > > get the symbols local to the block by iterating it?  That's not what > > the last sentence above seems to say.  It says that the symbols might > > be found in a different block, or something to that effect.  At least > > that's what I understand from reading it.  If my understanding is > > correct, how would my Python program that works today break with > > future versions of GDB? > > This is my thought: Take Tom's example of current 'globals' ending up > in a namespace block due to a future change. Now, this is just an > example. Meaning, a future existence of a namespace block is a > speculation now. Since it is a speculation, it could eventually so > happen that we will not have a namespace block but something else or > nothing at all. Hence, how things would change are unknown now, but > there is a chance that things will change. What Doug and Tom are > trying to say is that, "It is OK to use the API now and for some time > in future, but keep an eye out for changes and change accordingly." > Also, since how things would change in future is unknown now, it is > probably not possible to specify now as to how exactly would a Python > program break in future. OK, thanks. Then how about the following text? A @code{gdb.Block} is iterable. The iterator returns the symbols (@pxref{Symbols In Python}) local to the block. Python programs should not assume that a specific block object will always contain a given symbol, since changes in @value{GDBN} features and infrastructure may cause symbols move across blocks in a symbol table.