From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16859 invoked by alias); 27 Apr 2012 16:49:52 -0000 Received: (qmail 16846 invoked by uid 22791); 27 Apr 2012 16:49:50 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-vb0-f41.google.com (HELO mail-vb0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 27 Apr 2012 16:49:36 +0000 Received: by vbbey12 with SMTP id ey12so846725vbb.0 for ; Fri, 27 Apr 2012 09:49:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record :x-gm-message-state; bh=YzoUSK0ac6rd3h3aJytkT0NU/JVPEt0ZdhvPDhqW1Wg=; b=E/uiAu9ZYoeGb6gE8Q8BtmycmfkXbjHGVObNQ7YegRapfNxwp1MD0adS1QyB2TUSrQ yKCvQMcdv30RBy0TH4OxKKGTWrFokNnCDh9Ekf6kf1IS2U1gMaMqh7+NJjGhQEOoWrTL xRfzMkixiuc9qQuN0iwgyRuezX0zrfss1elcu9+Ic2jgBV+pC54KCoH3vtGWnEj7VGLh aeIz9hl1/i13SmIVRHxzbID9tmFj2QbvQdC779LNbq9vyafjiqQrLs6dCtdP4eKXzHF+ CSVuOH9gAQDlbR6u8baJFI/N7AhXuwQD5ZJIh7tUTHDTGuX2ucquaykB+iuOeTzsIC3q GDlQ== Received: by 10.52.67.208 with SMTP id p16mr10229223vdt.93.1335545375943; Fri, 27 Apr 2012 09:49:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.67.208 with SMTP id p16mr10229210vdt.93.1335545375787; Fri, 27 Apr 2012 09:49:35 -0700 (PDT) Received: by 10.52.165.2 with HTTP; Fri, 27 Apr 2012 09:49:35 -0700 (PDT) In-Reply-To: <83pqatgp9k.fsf@gnu.org> References: <83bomgfcbt.fsf@gnu.org> <87ipgna94k.fsf@fleche.redhat.com> <83y5pjedjp.fsf@gnu.org> <87397qa9a0.fsf@fleche.redhat.com> <83fwbqinsw.fsf@gnu.org> <83pqatgp9k.fsf@gnu.org> Date: Fri, 27 Apr 2012 16:59:00 -0000 Message-ID: Subject: Re: [RFC - doc] Add note about the possibility of symbols getting moved across blocks From: Doug Evans To: Eli Zaretskii , Siva Chandra Cc: tromey@redhat.com, gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true X-Gm-Message-State: ALoCoQkpTCco7G+A2GO6nLa2fp5ZWX/KpLvt+1AhuGjbD0uQ0tao7VQLR4HWwctxeKFzH1rewByBL+aJPNiW2Ug+zrj3qjdG7yV7PVeeqL3ILI56igdWSE2U5DmCse59IiwXXwRc2bkS9tlQvXpI3dOCU2qVK1R87Q== 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/msg01017.txt.bz2 On Fri, Apr 27, 2012 at 8:36 AM, Eli Zaretskii wrote: >> Date: Fri, 27 Apr 2012 16:33:06 +0530 >> From: Siva Chandra >> Cc: Tom Tromey , Doug Evans , gdb-pat= ches@sourceware.org >> >> On Thu, Apr 26, 2012 at 7:43 PM, Eli Zaretskii wrote: >> > Maybe I simply miss something important here. =A0The text in question >> > says this: >> > >> > =A0 A @code{gdb.Block} is iterable. =A0The iterator returns the symbols >> > =A0 (@pxref{Symbols In Python}) local to the block. =A0Users using this >> > =A0 feature should keep in mind that future improvements to the intern= al >> > =A0 representation, of symbols and symbol tables, can move symbols acr= oss >> > =A0 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? =A0That's not what >> > the last sentence above seems to say. =A0It says that the symbols might >> > be found in a different block, or something to that effect. =A0At least >> > that's what I understand from reading it. =A0If my understanding is >> > correct, how would my Python program that works today break with >> > future versions of GDB? >> >> This is my thought: =A0Take Tom's example of current 'globals' ending up >> in a namespace block due to a future change. =A0Now, this is just an >> example. =A0Meaning, a future existence of a namespace block is a >> speculation now. =A0Since it is a speculation, it could eventually so >> happen that we will not have a namespace block but something else or >> nothing at all. =A0Hence, how things would change are unknown now, but >> there is a chance that things will change. =A0What 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. Thanks Siva. > OK, thanks. =A0Then how about the following text? > > =A0A @code{gdb.Block} is iterable. =A0The iterator returns the symbols > =A0(@pxref{Symbols In Python}) local to the block. =A0Python programs > =A0should not assume that a specific block object will always contain a > =A0given symbol, since changes in @value{GDBN} features and > =A0infrastructure may cause symbols move across blocks in a symbol > =A0table. I think that's close enough. s/symbols move/symbols to move/ ?