From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11519 invoked by alias); 3 Apr 2012 00:04:22 -0000 Received: (qmail 11511 invoked by uid 22791); 3 Apr 2012 00:04:21 -0000 X-SWARE-Spam-Status: No, hits=-5.3 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-vx0-f169.google.com (HELO mail-vx0-f169.google.com) (209.85.220.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 03 Apr 2012 00:04:08 +0000 Received: by vcbfk14 with SMTP id fk14so2557867vcb.0 for ; Mon, 02 Apr 2012 17:04:07 -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=X65nRY5uczZPM1MQuhp1QofK7O2WbWRSLf2/dH+mwek=; b=E4XH980gZICOJlTfhvfhlM2jvZJORj1SAxl/OxhvutGYS8BGDsE9W3ZpLM+CY9YCLC sQmpr9ayMfKNkQsR/+p+4oSRSF5eJVqdatxlaZcosH3DvD+D4B4wJDBQdZdShxa3hFDA 6zKeo2IEOYPtsvWEL789cNBM85L1U+Haoms5wELZOuVrnN7iL9l3VQyx5HiIQ7J6HP0m JFLyisNRX3m752W26xJ1eDYazc/5L1z4ysJFZrOk3lQbr/usprm+AAPGpQpWeWu+hkM6 yuiUgWrK4cZL8LoztMVAKJyddWjF5LpPiHHPwHb8cOW80k455pHt3V8NSlQ3iVfuAuw7 HU/Q== Received: by 10.52.69.4 with SMTP id a4mr4033023vdu.87.1333411447663; Mon, 02 Apr 2012 17:04:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.69.4 with SMTP id a4mr4033017vdu.87.1333411447591; Mon, 02 Apr 2012 17:04:07 -0700 (PDT) Received: by 10.220.73.14 with HTTP; Mon, 2 Apr 2012 17:04:07 -0700 (PDT) In-Reply-To: References: Date: Tue, 03 Apr 2012 00:04:00 -0000 Message-ID: Subject: Re: [RFC - Python Scripting] New method Objfile.symtabs () - docs included From: Doug Evans To: Siva Chandra 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: ALoCoQkeXhjFRp/rx9kXjeTIhBYBbs4BtfvpsrcPiuKGA185ibRQ7QrkMrT5x/eWlZLrzW+/sgU98eOFLCZsiS3WndotNHX+hiPdt+5RwwWHcgqinGL5P2ThO4pSwwTv45s3kkHcv5YMX5FJl/NPWBcnUEbMk7zE/w== 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/msg00024.txt.bz2 On Sun, Apr 1, 2012 at 11:17 PM, Siva Chandra wrot= e: > Hi all, > > Attached is a patch which adds a new method Objfile.symtabs to > gdb.Objfile. =A0This new method returns a list of gdb.Symtab objects > associated with the underlying object file. > > Code ChangeLog: > > 2012-04-02 =A0Siva Chandra Reddy =A0 > > =A0 =A0 =A0 =A0Python Scripting: New method Objfile.symtabs which returns > =A0 =A0 =A0 =A0the list of obj.Symtab objects associated with the underly= ing > =A0 =A0 =A0 =A0objfile. > =A0 =A0 =A0 =A0* NEWS: Add entery under 'Python scripting' about the new spelling: "entry" > =A0 =A0 =A0 =A0Objfile.symtabs method. > =A0 =A0 =A0 =A0* python/py-objfile.c (stpy_iterator_object): New iterator > =A0 =A0 =A0 =A0object type to iterate over a list of obj.Symtab objects. > =A0 =A0 =A0 =A0(stpy_node): New struct to aid the iterator. > =A0 =A0 =A0 =A0(stpy_iterator_free_symtab_list, new_stpy_iterator, > =A0 =A0 =A0 =A0 objfpy_symtabs, stpy_iterator_dealloc, stpy_iterator_iter, > =A0 =A0 =A0 =A0 stpy_iterator_iternext): New functions which manage the n= ew > =A0 =A0 =A0 =A0iterator object type. > =A0 =A0 =A0 =A0(objfpy_dealloc, objfpy_new, objfile_to_objfile_object, > =A0 =A0 =A0 =A0 gdbpy_initialize_objfile): Add initializations and refere= nce > =A0 =A0 =A0 =A0management for the new iterator object and type. Hi. You're touching on one of the more troublesome areas of gdb (symbol handling), I salute your courage. :-) I didn't read the entire patch but one thing stood out: + /* If the symtabs are not yet read, then read them. */ + ALL_OBJFILE_PSYMTABS (objfile, psymtab) + { + if (psymtab->readin) + continue; + + if (psymtab->read_symtab) + psymtab->read_symtab (psymtab); + } This code is doing something we want to try really hard to avoid. In a large program this will push gdb's memory usage far beyond anything the user will find acceptable (not to mention taking a long time). We want to do the expansion as lazily as possible. [We also, IMO, want to expose as little of the symbol table implementation details in the Python API as possible, at least initially.] The current code may not make that easy (or even possible, absent changes), but if a simple and innocent looking my_objfile.symtabs() in Python can push gdb's memory usage to several 10s of gigabytes (assuming you have enough memory and swap :-)), then I think we need to avoid that. Assuming we want to provide the ability to iterate over all the symbol tables, we want to be able to do that without first expanding them. So I think the first question is what will the user want to do with this feature?