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

["Christian Biesinger via gdb-patches" <gdb-patches@sourceware.org>]

On Sun, Nov 10, 2019 at 4:27 PM Andrew Burgess
<andrew.burgess@embecosm.com> wrote:
>
> * Christian Biesinger <cbiesinger@google.com> [2019-11-09 00:23:00 -0600]:
>
> > On Mon, Nov 4, 2019 at 12:28 PM Simon Marchi <simark@simark.ca> wrote:
> > >
> > > On 2019-11-04 12:12 p.m., Andrew Burgess wrote:
> > > > How about I merged patches #1 and #2, but drop #3 for now?  This would
> > > > give:
> > > >
> > > >   lookup_static_symbol - returns the global static symbol for the
> > > >       current compilation unit, or whatever else GDB can find if
> > > >       there's nothing in the current CU.  This is basically inline
> > > >       with what we get from 'print symbol_name' at the CLI (if we
> > > >       limit symbol_name to just global static things).
> > > >
> > > > AND,
> > > >
> > > >   lookup_static_symbols - returns the list of all global static
> > > >       symbols.
> > > >
> > > > We no longer have a block parameter passed to 'lookup_static_symbol',
> > > > so hopefully and confusion can be avoided.  If/when we later add a
> > > > Python wrapper for CU we can _extend_ the API for lookup_static_symbol
> > > > to also take a CU and so provide the "look over there" type behaviour
> > > > in a clearer way.
> > > >
> > > > Would everyone be happy with this?
> > >
> > > I certainly would, I think that brings us back to the same place we were before
> > > it was suggested to add the block parameter, doesn't it?
> >
> > Sorry for the late reply & for confusing things -- yes, after reading
> > through all the discussions I think that's the best way forward.
>
> Thanks for the feedback.
>
> I've now pushed patches #1 and #2.

Thanks! By the way, should Objfile also get a lookup_static_symbols
method now, similar to Objfile.lookup_static_symbol?

(I don't personally have a use-case for this, but figured I should ask)

Christian