From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29644 invoked by alias); 5 Apr 2012 18:41:12 -0000 Received: (qmail 29634 invoked by uid 22791); 5 Apr 2012 18:41:12 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 05 Apr 2012 18:40:59 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q35IevNa004823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 5 Apr 2012 14:40:57 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q35Ieutj019660 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 5 Apr 2012 14:40:56 -0400 From: Tom Tromey To: Cc: , , Subject: Re: [RFC - Python Scripting] New method Objfile.symtabs () - docs included References: <09787EF419216C41A903FD14EE5506DD0313D5BF45@AUSX7MCPC103.AMER.DELL.COM> Date: Thu, 05 Apr 2012 18:41:00 -0000 In-Reply-To: <09787EF419216C41A903FD14EE5506DD0313D5BF45@AUSX7MCPC103.AMER.DELL.COM> (Paul Koning's message of "Thu, 5 Apr 2012 11:30:05 -0500") Message-ID: <87ehs2f2dk.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.95 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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/msg00079.txt.bz2 >>>>> "Paul" == writes: Paul> Those presumably live in a symtab but I didn't Paul> see a gdb.Symtab method to get them. (Is that the right approach? I Paul> can work on creating the machinery if this is the place for them, or Paul> if someone can point me to where in the gdb.* class hierarchy to fit Paul> this.) Yes, I think adding the ability to iterate over symbols in a symtab is the way to go. Actually, what Siva said sounds good, aside from the lazy CU instantiation issue: Siva> The exploration of symbols to look for functions can happen in Siva> this order: gdb.objfiles () => Objfile.symtabs () => Symtab.blocks Siva> () => Block.symbol => Symbol.name. Of course for your use, you won't care about lazy instantiation so much, since you will be expanding them all anyway. An extension to the earlier idea would be to make it possible to have the iterator take a symbol name to search for as well. This would let you instantiate many fewer CUs. This is more or less how the "quick" symbol API works. Tom