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

[Siva Chandra <sivachandra at google dot com>]

On Tue, Apr 3, 2012 at 5:34 AM, Doug Evans <dje@google.com> wrote:
>
> You're touching on one of the more troublesome areas of gdb (symbol
> handling), I salute your courage. :-)

I seem courageous as I do not know what awaits me. :-)

> 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?

Thanks for taking a look and starting a discussion on this.  An
example usage of this feature can be to implement something like run
time code path tracer.  This can probably be done in many other ways,
but I am using this as an example.  In this code path tracer, a user
might want to trace the function calls when between state A and state
B of program.  A way to do this from Python would be to get all the
function names and set internal breakpoints at these functions.  But
the user should first have a way to get the list of functions.  This
is where I thought the Objfile.symtabs becomes useful - The
exploration of symbols to look for functions can happen in this order:
gdb.objfiles () => Objfile.symtabs () => Symtab.blocks () =>
Block.symbol => Symbol.name.  This patch adding Objfile.symtabs () was
first of my patches towards completing this path.

Looking at it more generically, I thought that having the exploratory
path that I mention above available in the Python API completes a
'view' of GDB from a user's point.

For the memory problem you point out, do you think something like
Objfile.symtabs (regex, [symbol_type]) would be good?  REGEX is a file
name matcher to specify that only those symtabs whose source file
names match the REGEX should be loaded, and SYMBOL_TYPE is to specify
that only symbols of this kind should be loaded.  This can still be
abused to match everything and load everything, but it is at the
user's own peril.

Thanks,
Siva Chandra