This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


On Tue, Oct 15, 2019 at 2:28 PM Simon Marchi <simark@simark.ca> wrote:
>
> On 2019-10-15 12:46 p.m., Andrew Burgess wrote:
> > If gdb.lookup_static_symbol is going to return a single symbol then it
> > makes sense (I think) for it to return a context sensitive choice of
> > symbol, that is the static symbol that would be visible to the program
> > at that point.
>
> I remember discussing this with Christian, and I didn't have a strong option.  But
> now, I tend to agree with Andrew.
>
> 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?

Either way, I'm happy with this patch; I've come around to y'all's view.

Christian


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]