Re: [PATCH] gdb/python: Introduce gdb.lookup_all_static_symbols

[Andrew Burgess <andrew dot burgess at embecosm dot com>]

* Simon Marchi <simark@simark.ca> [2019-10-23 23:11:30 -0400]:

> On 2019-10-23 3:13 p.m., Andrew Burgess wrote:
> >>> I see two use cases here:
> >>>
> >>> 1. I want to get all static symbols named `foo`.  In which case, I'd use the
> >>>    function Andrew proposes in this patch.
> >>> 2. I want to get the static symbol named `foo` that's visible from a certain
> >>>    point, perhaps a given block or where my program is currently stopped at.
> >>>    Ideally, we would have a "CompilationUnit" object type in Python, such that
> >>>    I could use
> >>>
> >>>     block.compunit.lookup_static_symbol('foo')
> >>>
> >>>   or
> >>>
> >>>     gdb.current_compunit().lookup_static_symbol('foo')
> >> So technically, those don't give you "the static symbol named `foo`
> >> that's visible from [this] point", because there could be static
> >> variable in the function.
> >>
> >> Since we already have block objects, should this new function
> >> optionally take a block to start the lookup in?
> > When you say "new function", I assume you mean
> > 'gdb.lookup_static_symbol' not 'gdb.lookup_static_symbols', as the
> > second one always returns all symbols.
> > 
> > Anyway, I took a stab at adding a block parameter to the first of
> > these functions - is this what you were thinking?
> > 
> > Thanks,
> > Andrew
> 
> I'm confused, I don't gdb.lookup_static_symbol(s) only look through
> static symbols, as in file-level static variables?

So, before patch 3 the situation was:

  gdb.lookup_static_symbol

  Return the file level static symbol matching a given name.  Will
  return the static from the current file first, before searching
  through all other files.  This matches the CLI behaviour for if you
  just typed: 'print var_name' (with var_name being file-level
  static).

  gdb.lookup_static_symbols

  Returns all of the file level static symbols matching a given name,
  the order corresponds to the order of the compilation units as found
  by GDB (I guess).  In general a user shouldn't read any meaning into
  the order, just that these are all file level statics with that
  name.

The last patch in the series modifies the first of these to take an
optional block parameter.  GDB will then find the file level static
that would be seen from that block.

This allows the user to ask the question, what file-level static would
I see from over there, without actually having to be "over there".

This is demonstrated in the testsuite changes where I lookup a block
based on a $pc from some other function in a different file, I can
then query the file-level static that would be visible from that
function.

Is this super useful? I don't know, I think this is what Christian was
suggesting and adding the feature was both easy to implement and easy
to test, so I figured why not.

Thanks,
Andrew