From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32181 invoked by alias); 20 Apr 2012 04:58:11 -0000 Received: (qmail 32169 invoked by uid 22791); 20 Apr 2012 04:58:09 -0000 X-SWARE-Spam-Status: No, hits=-5.1 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-qc0-f169.google.com (HELO mail-qc0-f169.google.com) (209.85.216.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Apr 2012 04:57:57 +0000 Received: by qcsd16 with SMTP id d16so6546219qcs.0 for ; Thu, 19 Apr 2012 21:57:56 -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:x-system-of-record:x-gm-message-state; bh=aHsJ4pHjGjYAUfebQwM/hLzb6icNErra7JAZ3VOOESY=; b=TJehSxJkRL9uIjs5JJEnfXhBJ1piKBexFFlgVdnN2Z6mV5YnHvHtA/Hz4+mr9+OYz+ axu1ZaVKU5ssxrEmP3c+RFoxnhtgMsoMD0/IDoNCOBxscfv1KC0/Nv4mYBWBbqn+emqJ tEqULeugThIbq/imXk2BDi92tb2Og/4XPMsiFq8iYHFtD156mRq+5RRxqiUwCqbagHxv lr851J/E6esJZEnKxt8rja8SUfy1uGBVuK6I/wOUkSQzkLWMNWugDTrY2ZNd8WY2+BK2 DOkCpKYcyzZbJcZ2ANbt/2xv3mz0K1VUtx83BAswcxpaUxVjHZE36dgFSadpcyaZR8Pd lP2A== Received: by 10.229.137.7 with SMTP id u7mr1835097qct.10.1334897876470; Thu, 19 Apr 2012 21:57:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.229.137.7 with SMTP id u7mr1835089qct.10.1334897876262; Thu, 19 Apr 2012 21:57:56 -0700 (PDT) Received: by 10.224.35.2 with HTTP; Thu, 19 Apr 2012 21:57:56 -0700 (PDT) In-Reply-To: References: <831unms3jy.fsf@gnu.org> <4F8F187D.3050402@redhat.com> <878vhsojgd.fsf@fleche.redhat.com> Date: Fri, 20 Apr 2012 06:48:00 -0000 Message-ID: Subject: Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included) From: Siva Chandra To: Doug Evans Cc: Tom Tromey , Phil Muldoon , Eli Zaretskii , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true X-Gm-Message-State: ALoCoQlpKCzy9HOI8RoZJhUiGnd3NLiP95ng/c3z5aAXRqm5qIRlPKR93IunpPnbLILCk/TD+pPaXtvNanyLTC3syA6qMcmuXR7iAc3UiPuOMW/DxhWH1PrArKyH+RwhKQHil8VAqHxDfn+DYgVZBgSnYtAHqsaNNQ== 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/msg00659.txt.bz2 Doug> It would not be unexpected to me if a symbol disappeared from either Doug> list, moved from one list to another, or a new symbol appeared. Even in the API currently public, Block.superblock can take a user to global or static block and make him/her vulnerable to the above problem. But, can we view this from a different angle: Let us first take the case of a global block. As I understand, this should very definitely contain the global functions and global variables defined in a source file. If these two kinds of symbols do not change from release to release, then we document saying that the user should rely only on this information being constant. Similarly, if my understanding is correct, static functions and static variables defined in a source file should always be present in a static block. Hence, we again document saying that the user rely only on this information being constant. Does this sound reasonable?