From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8232 invoked by alias); 26 Apr 2012 14:14:16 -0000 Received: (qmail 7994 invoked by uid 22791); 26 Apr 2012 14:14:13 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_NO,RCVD_IN_NIX_SPAM,SPF_SOFTFAIL X-Spam-Check-By: sourceware.org Received: from mtaout22.012.net.il (HELO mtaout22.012.net.il) (80.179.55.172) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 26 Apr 2012 14:14:01 +0000 Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M3300D00BFEUV00@a-mtaout22.012.net.il> for gdb-patches@sourceware.org; Thu, 26 Apr 2012 17:13:18 +0300 (IDT) Received: from HOME-C4E4A596F7 ([84.229.249.186]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M3300DN7BI5PA50@a-mtaout22.012.net.il>; Thu, 26 Apr 2012 17:13:18 +0300 (IDT) Date: Thu, 26 Apr 2012 14:17:00 -0000 From: Eli Zaretskii Subject: Re: [RFC - doc] Add note about the possibility of symbols getting moved across blocks In-reply-to: <87397qa9a0.fsf@fleche.redhat.com> To: Tom Tromey Cc: sivachandra@google.com, gdb-patches@sourceware.org Reply-to: Eli Zaretskii Message-id: <83fwbqinsw.fsf@gnu.org> References: <83bomgfcbt.fsf@gnu.org> <87ipgna94k.fsf@fleche.redhat.com> <83y5pjedjp.fsf@gnu.org> <87397qa9a0.fsf@fleche.redhat.com> 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/msg00907.txt.bz2 > From: Tom Tromey > Cc: sivachandra@google.com, gdb-patches@sourceware.org > Date: Thu, 26 Apr 2012 07:54:15 -0600 > > I think the idea is to warn Python developers that they should test > their code with future versions if they use this feature. > Normally we try to maintain compatibility, even when we've made mistakes. > But in this case, we suspect we may make changes and we don't want to > promise compatibility; but nor do we want to block this feature until > the symbol tables are changed, since that may not happen for some time. 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?