From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32567 invoked by alias); 17 Apr 2012 17:27:24 -0000 Received: (qmail 32550 invoked by uid 22791); 17 Apr 2012 17:27:22 -0000 X-SWARE-Spam-Status: No, hits=-5.0 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,TW_BJ,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; Tue, 17 Apr 2012 17:27:09 +0000 Received: by qcsd16 with SMTP id d16so4599460qcs.0 for ; Tue, 17 Apr 2012 10:27:08 -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=BjhEmVPLn2uZz0J6I/aOasPxpAN5TFbZHGVhtxh1YDs=; b=eA0Y2enDZ2JZLDw3YczvJVrB0ARAMEI2LSN8VvalcoOrhbE68C4BEGBxVax8iNhDje cNznZWxYJ/TfQsqzDZajpN4H0C3O2dIAwrAzgk1g9rFXZHJ6M0ndk79yG7BR6nj2fzdX I8ErJcTYEgfpmOOo6+nn6BkCitHRLyTDkUIl8WTt65vtZkrpeoKKISRQLQIwDb/axHwB I+ZbfsNeBo0kLvStpFsJnTUj20jWw51p4PDEXkSE3t6/jkH7mJrC7JfZHsVQyLhGoHF7 72rn8en7LBObS98oCOw5Xu4ryasuF5CgPC5jNooJ8GPBQUBha3+6WRI/Veb1GVXtb4xL /5gQ== Received: by 10.224.215.7 with SMTP id hc7mr13634887qab.29.1334683628413; Tue, 17 Apr 2012 10:27:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.215.7 with SMTP id hc7mr13634829qab.29.1334683627704; Tue, 17 Apr 2012 10:27:07 -0700 (PDT) Received: by 10.224.35.2 with HTTP; Tue, 17 Apr 2012 10:27:07 -0700 (PDT) In-Reply-To: <4F8D6779.8090906@redhat.com> References: <4F8D6779.8090906@redhat.com> Date: Tue, 17 Apr 2012 17:34:00 -0000 Message-ID: Subject: Re: [RFC - Python scripting] New methods Symtab.global_block and Symtab.static_block (docs included) From: Siva Chandra To: Phil Muldoon Cc: 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: ALoCoQlyFxhXuGf9uxVEC8m+wegoLj/tHNsErYaZMtgONYSYjo+tcpzq5FXNBxeyuOtjIiMhno5/Z0/diQ3q2DpPX39OEwE+nhpuEt+nbR6xPWk9C6cz4I94A8euYE4YKXzXI+WlfZ9COihnz6S/7Tg6VKECQQybhQ== 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/msg00504.txt.bz2 Thank Phil, for taking a look. Comments below. Phil> We already have gdb.Block.is_static and gdb.Block.is_global. =A0I don= 't Phil> have an objection to this patch per-se, but wouldn't the user acquire Phil> the global/static blocks similarly by iterating the blocks in the Phil> Python code and doing the above tests? Is there a way to iterate over all blocks of a Symtab right after loading? If yes, my mistake for having missed it, and this patch is not necessary. The idea behind most of the patches I am sending is to have an exploratory path Objfile =3D> Symtab =3D> Block =3D> Symbol. This part addresses Symtab =3D> Block part but not completely; good enough for my immediate needs though. Phil> I don't think GNU Style ChangeLogs allow for a summary line. =A0I don= 't Phil> have an issue with it, but, check with maintainers. =A0Just a nit. There many examples in ChangeLog with a summary line. There are of course many others without :-) >> +static PyObject * >> +stpy_global_block (PyObject *self, PyObject *args) >> +{ >> + =A0struct symtab *symtab =3D NULL; >> > + =A0struct block *block =3D NULL; >> + >> + =A0STPY_REQUIRE_VALID (self, symtab); >> + >> + =A0block =3D symtab->blockvector->block[GLOBAL_BLOCK]; >> + =A0return block_to_block_object (block, symtab->objfile); Phil> I don't think so, but can block ever be NULL here? =A0Looking at the Phil> code, I'm not even sure if it would matter as set_block just stores a Phil> reference to the passed block. =A0However, blpy_get_superblock has a Phil> NULL block check, so it might be worthwhile checking it out. As I understand, blpy_get_superblock has a check, as the top most block will not have a superblock. In which case, returning None is probably more appropriate (as it is a logically valid situation) than returning a NULL. However, in the case of this patch, is there a chance that a symtab->blockvector->nblocks =3D=3D 0? Similarly, is there a chance blockvector->nblocks > 0 but blockvector->block[GLOBAL_BLOCK] (or blockvector->block[STATIC_BLOCK]) is NULL for a logical valid situation? Thanks, Siva Chandra