Re: [RFC - Python Scripting] New method Objfile.symtabs () - docs included

[Doug Evans <dje@google.com>]

On Sun, Apr 1, 2012 at 11:17 PM, Siva Chandra <sivachandra@google.com> wrote:
> Hi all,
>
> Attached is a patch which adds a new method Objfile.symtabs to
> gdb.Objfile.  This new method returns a list of gdb.Symtab objects
> associated with the underlying object file.
>
> Code ChangeLog:
>
> 2012-04-02  Siva Chandra Reddy  <sivachandra@google.com>
>
>        Python Scripting: New method Objfile.symtabs which returns
>        the list of obj.Symtab objects associated with the underlying
>        objfile.
>        * NEWS: Add entery under 'Python scripting' about the new

spelling: "entry"

>        Objfile.symtabs method.
>        * python/py-objfile.c (stpy_iterator_object): New iterator
>        object type to iterate over a list of obj.Symtab objects.
>        (stpy_node): New struct to aid the iterator.
>        (stpy_iterator_free_symtab_list, new_stpy_iterator,
>         objfpy_symtabs, stpy_iterator_dealloc, stpy_iterator_iter,
>         stpy_iterator_iternext): New functions which manage the new
>        iterator object type.
>        (objfpy_dealloc, objfpy_new, objfile_to_objfile_object,
>         gdbpy_initialize_objfile): Add initializations and reference
>        management 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?