From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23082 invoked by alias); 20 Apr 2012 11:44:10 -0000 Received: (qmail 23070 invoked by uid 22791); 20 Apr 2012 11:44:09 -0000 X-SWARE-Spam-Status: No, hits=-5.1 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-yw0-f41.google.com (HELO mail-yw0-f41.google.com) (209.85.213.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 20 Apr 2012 11:43:56 +0000 Received: by yhr47 with SMTP id 47so6072120yhr.0 for ; Fri, 20 Apr 2012 04:43:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.135.38 with SMTP id m38mr1719563ann.64.1334922235672; Fri, 20 Apr 2012 04:43:55 -0700 (PDT) Received: by 10.236.115.200 with HTTP; Fri, 20 Apr 2012 04:43:55 -0700 (PDT) In-Reply-To: References: <831unms3jy.fsf@gnu.org> <4F8F187D.3050402@redhat.com> <878vhsojgd.fsf@fleche.redhat.com> Date: Fri, 20 Apr 2012 12:12:00 -0000 Message-ID: Subject: Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included) From: Matt Rice To: Siva Chandra Cc: Doug Evans , Tom Tromey , Phil Muldoon , Eli Zaretskii , gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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/msg00671.txt.bz2 On Thu, Apr 19, 2012 at 9:57 PM, Siva Chandra wrot= e: > =A0Similarly, 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. =A0Does this sound reasonable? I personally don't know a lot about this area, but I do recall seeing some comments which hint at the unreliability in this. I can't find the specific comment I went looking for, which I recall as saying that sometimes it is a 'best guess'. could be a figment of my imagination the following from (possibly outdated) symtab.c stuff is what i did find, i believe there is other uncommented occurrences, anyhow given the fudge and lack of errors I wouldn't be suprised to weirdness here go unnoticed. int other_kind =3D kind =3D=3D GLOBAL_BLOCK ? STATIC_BLOCK : GLOBAL_B= LOCK; /* This shouldn't be necessary, but as a last resort * try looking in the 'other kind' even though the psymtab * claimed the symbol was one thing. It's possible that * the psymtab gets it wrong in some cases. */ block =3D BLOCKVECTOR_BLOCK (bv, other_kind); sym =3D lookup_block_symbol (block, name, STRUCT_DOMAIN); .... /* This shouldn't be necessary, but as a last resort try looking in the statics even though the psymtab claimed the symbol was global, or vice-versa. It's possible that the psymtab gets it wrong in some cases. */ /* FIXME: carlton/2002-09-30: Should we really do that? If that happens, isn't it likely to be a GDB error, in which case we should fix the GDB error rather than silently dealing with it here? So I'd vote for removing the check for the symbol in the other block. */ block =3D BLOCKVECTOR_BLOCK (bv, kind =3D=3D GLOBAL_BLOCK ? STATIC_BLOCK : GLOBAL_BLOCK);