Re: [PATCH][PR/24474] Make gdb.lookup_static_symbol also check the STATIC_SCOPE

[Simon Marchi <simark@simark.ca>]

On 2019-06-04 9:24 p.m., Christian Biesinger via gdb-patches wrote:
> gdb/ChangeLog:
> 
> 2019-06-04  Christian Biesinger  <cbiesinger@google.com>
> 
> 	PR/24474: Make gdb.lookup_global_symbol also check the STATIC_SCOPE
> 	because from a C/C++ developer's perspective, these are also globals.
> 	* NEWS: Mention this change.
> 	* python/py-symbol.c (gdbpy_lookup_global_symbol): Call
> 	lookup_static_symbol if lookup_global_symbol returns NULL.
> 
> gdb/testsuite/ChangeLog:
> 
> 2019-06-04  Christian Biesinger  <cbiesinger@google.com>
> 
> 	* gdb.python/py-symbol.c: Add a static variable and one in an anonymous
> 	namespace.
> 	* gdb.python/py-symbol.exp: Check that lookup_global_symbol finds those
> 	variables.

Hi Christian,

Sorry for the delay, I'll try to help you with this.

I am not sure this is the right thing to do, or at least some things need to be
clarified.  Global symbols are visible through the entire program (there can only
be one of that name), whereas there can be many static symbols with the same name.
What should the user expect if there are multiple static symbols with the same name?
I suppose we'll return the first one that matches, without any particular guarantee
about which one.

It is possible to get to a particular static symbol using gdb.lookup_symbol, provided
you pass a block that is under the right static block, and that no other symbol shadows
this one from the point of view of the block.  But IIRC, it can prove difficult to get
access the static block of a particular compilation unit (if you don't yet have a reference
to a frame block under that static block).

<thought drift>
I have been thinking for a while that we are missing the concept of compilation units in
our Python API, that would be the bridge between objfiles and global/static blocks.

- From an objfile, you could list all included compilation units or search through them
- From the compilation unit, you could obtain its global/static block.

From there, you could use gdb.lookup_symbol, passing the static block of the compilation unit.

However, in my (naive) attempt at adding compunits to the Python API [1], which consisted of
wrapping compunit_symtab objects in Python, the problem I faced is that compunit_symtab objects
are not created until full symbols are read.  So unless you used -readnow, you would not
see all the compilation units you would expect (because they are lazily created).
</thought drift>

Would it be an option to add a gdb.lookup_static_symbol function, that would only look through
the static blocks?  Its behavior could be that if you don't pass a block, it searches through
all the static blocks until it finds a matching symbol (just like your patch does with
gdb.lookup_global_symbol if no symbol is found).  And if you pass a block, it restricts the
search to the static block linked to that block, ensuring you find the static symbol you want.

Simon

[1] https://github.com/simark/binutils-gdb/commits/py-compunit