Message ID | 20191023191354.GH4962@embecosm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 13871 invoked by alias); 23 Oct 2019 19:14:02 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 13853 invoked by uid 89); 23 Oct 2019 19:14:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-22.5 required=5.0 tests=AWL, BAYES_05, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, KAM_STOCKGEN, RCVD_IN_DNSWL_NONE, SPF_PASS autolearn=ham version=3.3.1 spammy=D*r, Grab, U*simark, simarksimarkca X-HELO: mail-wr1-f50.google.com Received: from mail-wr1-f50.google.com (HELO mail-wr1-f50.google.com) (209.85.221.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Oct 2019 19:13:58 +0000 Received: by mail-wr1-f50.google.com with SMTP id l10so22891456wrb.2 for <gdb-patches@sourceware.org>; Wed, 23 Oct 2019 12:13:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=Xtgq6AxoTmHwrM83VAXQem/7L6ZJJeb/o1BaTypJqKI=; b=G3Y7dhPUztU0ghyIU7t7pOl3oQ277aTqIIlRwoBeTXQekb6fTcNXC5CagxQMn0LdW9 OKjvkyjh+2CF/i/8eCuLGUIsiDhVCYlsilc2sV8y8168MkeCxTogNHHYe6hCO/pBpq10 JoYBMuwRjQSS/fzkAvrWfI24O+TqaE77D+ZGp+XnrWlUzhdPNuqh9rCsVhuVAzk0jJ7B cUitLM/Q/Acv/4AMLG20muw+dtCbJEqiG7cWjE2DPDbButgGYrpzWcwJjMOzURs6yB0b Gsz3bmdHd2XAiGCWcj++s8YjnV13P8PtmckkbUScmCxHQyGwIIoaPjN5WwWHyzgxQGaM eWsg== Return-Path: <andrew.burgess@embecosm.com> Received: from localhost (host86-128-12-122.range86-128.btcentralplus.com. [86.128.12.122]) by smtp.gmail.com with ESMTPSA id x12sm13087887wru.93.2019.10.23.12.13.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 23 Oct 2019 12:13:55 -0700 (PDT) Date: Wed, 23 Oct 2019 20:13:54 +0100 From: Andrew Burgess <andrew.burgess@embecosm.com> To: Christian Biesinger <cbiesinger@google.com> Cc: Simon Marchi <simark@simark.ca>, gdb-patches <gdb-patches@sourceware.org> Subject: Re: [PATCH] gdb/python: Introduce gdb.lookup_all_static_symbols Message-ID: <20191023191354.GH4962@embecosm.com> References: <20191015141515.GW4962@embecosm.com> <20191015164647.1837-1-andrew.burgess@embecosm.com> <32eba92d-55a9-5694-cec5-80001d8ff1ae@simark.ca> <CAPTJ0XEAtJRp=zCLWzvtMidZSXNnDkdy-OxafHeNSA3SuOVQ5w@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <CAPTJ0XEAtJRp=zCLWzvtMidZSXNnDkdy-OxafHeNSA3SuOVQ5w@mail.gmail.com> X-Fortune: Don't feed the bats tonight. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes |
Commit Message
Andrew Burgess
Oct. 23, 2019, 7:13 p.m. UTC
* Christian Biesinger <cbiesinger@google.com> [2019-10-21 17:36:37 -0500]: > 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? 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 --- commit 62d488878b467dd83a9abffc6dc3c67c2da82e85 Author: Andrew Burgess <andrew.burgess@embecosm.com> Date: Wed Oct 23 15:08:42 2019 +0100 gdb/python: New block parameter for gdb.lookup_static_symbol Adds a new block parameter to gdb.lookup_static_symbol. Currently gdb.lookup_static_symbol first looks in the global static scope of the current block for a matching symbol, and if non is found it then looks in all other global static scopes. The new block parameter for gdb.lookup_static_symbol allows the user to search the global static scope for some other block rather than the current block if they so desire. If the block parameter is no given, or is given as None, then GDB will search using the current block first (this matches the CLI behaviour). I added the block parameter to the middle of the parameter list, so the parameter order is 'symbol block domain', this matches the order of the other symbol lookup function that takes a block 'lookup_symbol' which also has the order 'symbol block domain'. I think changing the API like this is fine as the 'gdb.lookup_static_symbol' has not been in any previous GDB release, so there should be no existing user scripts that use this function. The documentation for gdb.lookup_static_symbol has been reordered so that the block parameter can be explained early on, and I've added some tests. gdb/ChangeLog: * python/py-symbol.c (gdbpy_lookup_static_symbol): Accept and handle a new block parameter. gdb/testsuite/ChangeLog: * gdb.python/py-symbol.exp: Add tests for passing a block parameter to gdb.lookup_static_symbol. gdb/doc/ChangeLog: * python.texi (Symbols In Python): Rewrite documentation for gdb.lookup_static_symbol, including adding a description of the new block parameter. Change-Id: I132a7f0934ba029c9f32058e9341a6c7cb975606
Comments
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? Simon
* 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
On Wed, Oct 23, 2019 at 2:13 PM Andrew Burgess <andrew.burgess@embecosm.com> wrote: > > * Christian Biesinger <cbiesinger@google.com> [2019-10-21 17:36:37 -0500]: > > > 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? > > 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? I'm sorry, I think I was a bit confused when I wrote that. Here's what I was thinking about -- with your change to make lookup_static_symbol produce the same result as "print var", it will also find block-level statics. However, lookup_static_symbols only looks at file-level static variables, which means that lookup_static_symbol can find a variable that's not in lookup_static_symbols, which seems confusing to users. My suggestion to give it a block to start in didn't really make sense, I think, but it would be good to think about that a bit more? Christian > > Thanks, > Andrew > > --- > > commit 62d488878b467dd83a9abffc6dc3c67c2da82e85 > Author: Andrew Burgess <andrew.burgess@embecosm.com> > Date: Wed Oct 23 15:08:42 2019 +0100 > > gdb/python: New block parameter for gdb.lookup_static_symbol > > Adds a new block parameter to gdb.lookup_static_symbol. Currently > gdb.lookup_static_symbol first looks in the global static scope of the > current block for a matching symbol, and if non is found it then looks > in all other global static scopes. > > The new block parameter for gdb.lookup_static_symbol allows the user > to search the global static scope for some other block rather than the > current block if they so desire. > > If the block parameter is no given, or is given as None, then GDB will > search using the current block first (this matches the CLI behaviour). > > I added the block parameter to the middle of the parameter list, so > the parameter order is 'symbol block domain', this matches the order > of the other symbol lookup function that takes a block 'lookup_symbol' > which also has the order 'symbol block domain'. I think changing the > API like this is fine as the 'gdb.lookup_static_symbol' has not been > in any previous GDB release, so there should be no existing user > scripts that use this function. > > The documentation for gdb.lookup_static_symbol has been reordered so > that the block parameter can be explained early on, and I've added > some tests. > > gdb/ChangeLog: > > * python/py-symbol.c (gdbpy_lookup_static_symbol): Accept and > handle a new block parameter. > > gdb/testsuite/ChangeLog: > > * gdb.python/py-symbol.exp: Add tests for passing a block > parameter to gdb.lookup_static_symbol. > > gdb/doc/ChangeLog: > > * python.texi (Symbols In Python): Rewrite documentation for > gdb.lookup_static_symbol, including adding a description of the > new block parameter. > > Change-Id: I132a7f0934ba029c9f32058e9341a6c7cb975606 > > diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi > index a30c8ae4f03..fe984a06b98 100644 > --- a/gdb/doc/python.texi > +++ b/gdb/doc/python.texi > @@ -4853,31 +4853,41 @@ > @end defun > > @findex gdb.lookup_static_symbol > -@defun gdb.lookup_static_symbol (name @r{[}, domain@r{]}) > -This function searches for a global symbol with static linkage by name. > -The search scope can be restricted to by the domain argument. > +@defun gdb.lookup_static_symbol (name @r{[}, block @r{[}, domain@r{]]}) > +This function searches for a global symbol with static linkage by > +name. > > @var{name} is the name of the symbol. It must be a string. > -The optional @var{domain} argument restricts the search to the domain type. > -The @var{domain} argument must be a domain constant defined in the @code{gdb} > -module and described later in this chapter. > - > -The result is a @code{gdb.Symbol} object or @code{None} if the symbol > -is not found. > - > -Note that this function will not find function-scoped static variables. To look > -up such variables, iterate over the variables of the function's > -@code{gdb.Block} and check that @code{block.addr_class} is > -@code{gdb.SYMBOL_LOC_STATIC}. > > There can be multiple global symbols with static linkage with the same > name. This function will only return the first matching symbol that > it finds. Which symbol is found depends on where @value{GDBN} is > currently stopped, as @value{GDBN} will first search for matching > -symbols in the current object file, and then search all other object > -files. If the application is not yet running then @value{GDBN} will > -search all object files in the order they appear in the debug > -information. > +symbols in the global static scope of the current object file, and > +then search all other object files. This corresponds to the behaviour > +you would see from the CLI if you tried to print the symbol by name. > + > +If the application is not yet running then @value{GDBN} will search > +all object files in the order they appear in the debug information. > + > +The optional @var{domain} argument restricts the search to the domain > +type. The @var{domain} argument must be a domain constant defined in > +the @code{gdb} module and described later in this chapter. > + > +The optional @var{block} argument can be used to change which global > +static scope @value{GDBN} will search first. If @var{block} is not > +given, or is passed the value @code{None} then @value{GDBN} will first > +search the global static scope corresponding to the current block. If > +@var{block} is passed a @code{gdb.Block} then @value{GDBN} will first > +search the global static scope corresponding to the supplied block. > + > +The result is a @code{gdb.Symbol} object or @code{None} if the symbol > +is not found. > + > +Note that this function will not find function-scoped static > +variables. To look up such variables, iterate over the variables of > +the function's @code{gdb.Block} and check that @code{block.addr_class} > +is @code{gdb.SYMBOL_LOC_STATIC}. > @end defun > > @findex gdb.lookup_global_symbol > diff --git a/gdb/python/py-symbol.c b/gdb/python/py-symbol.c > index 647c54b0a5b..24b3f6f4376 100644 > --- a/gdb/python/py-symbol.c > +++ b/gdb/python/py-symbol.c > @@ -473,19 +473,20 @@ gdbpy_lookup_global_symbol (PyObject *self, PyObject *args, PyObject *kw) > } > > /* Implementation of > - gdb.lookup_static_symbol (name [, domain]) -> symbol or None. */ > + gdb.lookup_static_symbol (name [, block] [, domain]) -> symbol or None. */ > > PyObject * > gdbpy_lookup_static_symbol (PyObject *self, PyObject *args, PyObject *kw) > { > const char *name; > int domain = VAR_DOMAIN; > - static const char *keywords[] = { "name", "domain", NULL }; > + static const char *keywords[] = { "name", "block", "domain", NULL }; > struct symbol *symbol = NULL; > + PyObject *block_obj = NULL; > PyObject *sym_obj; > > - if (!gdb_PyArg_ParseTupleAndKeywords (args, kw, "s|i", keywords, &name, > - &domain)) > + if (!gdb_PyArg_ParseTupleAndKeywords (args, kw, "s|O|i", keywords, &name, > + &block_obj, &domain)) > return NULL; > > /* In order to find static symbols associated with the "current" object > @@ -493,16 +494,22 @@ gdbpy_lookup_static_symbol (PyObject *self, PyObject *args, PyObject *kw) > we can acquire a current block. If this fails however, then we still > want to search all static symbols, so don't throw an exception just > yet. */ > - const struct block *block = NULL; > - try > - { > - struct frame_info *selected_frame > - = get_selected_frame (_("No frame selected.")); > - block = get_frame_block (selected_frame, NULL); > - } > - catch (const gdb_exception &except) > + const struct block *block = nullptr; > + if (block_obj) > + block = block_object_to_block (block_obj); > + > + if (block == nullptr) > { > - /* Nothing. */ > + try > + { > + struct frame_info *selected_frame > + = get_selected_frame (_("No frame selected.")); > + block = get_frame_block (selected_frame, NULL); > + } > + catch (const gdb_exception &except) > + { > + /* Nothing. */ > + } > } > > try > diff --git a/gdb/testsuite/gdb.python/py-symbol.exp b/gdb/testsuite/gdb.python/py-symbol.exp > index ea41297f54f..0ffe07df5a8 100644 > --- a/gdb/testsuite/gdb.python/py-symbol.exp > +++ b/gdb/testsuite/gdb.python/py-symbol.exp > @@ -87,6 +87,10 @@ if ![runto_main] then { > > global hex decimal > > +# Grab the value of $pc, we'll use this later. > +set pc_val_file_1 [get_integer_valueof "\$pc" 0 \ > + "get value of \$pc in main file"] > + > gdb_breakpoint [gdb_get_line_number "Block break here."] > gdb_continue_to_breakpoint "Block break here." > gdb_py_test_silent_cmd "python frame = gdb.selected_frame()" "Get Frame" 0 > @@ -116,7 +120,18 @@ gdb_test "python print (func.addr_class == gdb.SYMBOL_LOC_BLOCK)" "True" "test f > gdb_breakpoint "function_in_other_file" > gdb_continue_to_breakpoint "function_in_other_file" > gdb_test "python print (gdb.lookup_static_symbol ('rr').value ())" "99" \ > - "print value of rr from other file" > + "print value of rr from other file, don't pass a block value" > +gdb_test "python print (gdb.lookup_static_symbol ('rr', None).value ())" "99" \ > + "print value of rr from other file, pass block value of None" > + > +# Test gdb.lookup_static_symbol passing a block parameter > +set pc_val_file_2 [get_integer_valueof "\$pc" 0 \ > + "get \$pc in other file"] > +gdb_test "python print (gdb.lookup_static_symbol ('rr', gdb.current_progspace ().block_for_pc (${pc_val_file_2})).value ())" "99" \ > + "print value of rr from other file, pass block for other file" > +gdb_test "python print (gdb.lookup_static_symbol ('rr', gdb.current_progspace ().block_for_pc (${pc_val_file_1})).value ())" "42" \ > + "print value of rr from other file, pass block for main file" > + > gdb_test "python print (gdb.lookup_static_symbols ('rr')\[0\].value ())" "99" \ > "print value of gdb.lookup_static_symbols ('rr')\[0\], from the other file" > gdb_test "python print (gdb.lookup_static_symbols ('rr')\[1\].value ())" "42" \ > @@ -131,7 +146,14 @@ gdb_py_test_silent_cmd "python frame = gdb.selected_frame()" "Get Frame" 0 > # Check that we find the static sybol local to this file over the > # static symbol from the second source file. > gdb_test "python print (gdb.lookup_static_symbol ('rr').value ())" "42" \ > - "print value of rr from main file" > + "print value of rr from main file, passing no block parameter" > +gdb_test "python print (gdb.lookup_static_symbol ('rr', None).value ())" "42" \ > + "print value of rr from main file, passing None block parameter" > +gdb_test "python print (gdb.lookup_static_symbol ('rr', gdb.current_progspace ().block_for_pc (${pc_val_file_2})).value ())" "99" \ > + "print value of rr from main file, pass block for other file" > +gdb_test "python print (gdb.lookup_static_symbol ('rr', gdb.current_progspace ().block_for_pc (${pc_val_file_1})).value ())" "42" \ > + "print value of rr from main file, pass block for main file" > + > gdb_test "python print (gdb.lookup_static_symbols ('rr')\[0\].value ())" "99" \ > "print value of gdb.lookup_static_symbols ('rr')\[0\], from the main file" > gdb_test "python print (gdb.lookup_static_symbols ('rr')\[1\].value ())" "42" \
* Christian Biesinger <cbiesinger@google.com> [2019-10-28 00:07:17 -0500]: > On Wed, Oct 23, 2019 at 2:13 PM Andrew Burgess > <andrew.burgess@embecosm.com> wrote: > > > > * Christian Biesinger <cbiesinger@google.com> [2019-10-21 17:36:37 -0500]: > > > > > 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? > > > > 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? > > I'm sorry, I think I was a bit confused when I wrote that. Here's what > I was thinking about -- with your change to make lookup_static_symbol > produce the same result as "print var", it will also find block-level > statics. However, lookup_static_symbols only looks at file-level > static variables, which means that lookup_static_symbol can find a > variable that's not in lookup_static_symbols, which seems confusing to > users. My suggestion to give it a block to start in didn't really make > sense, I think, but it would be good to think about that a bit more? This is not correct, both lookup_static_symbol AND lookup_static_symbols BOTH only lookup file level static globals. [ SIDE-ISSUE : The name for both of these is obviously a possible sauce of confusion, maybe before this function makes it into a release we should consider renaming it/them? How about lookup_static_global(s) ? ] Here's a demo session using the above 3 patches, the test file is: static int global_v1 = 1; static int global_v2 = 2; int use_them () { return global_v1 + global_v2; } int main () { static int global_v2 = 3; static int global_v3 = 4; return use_them () + global_v2 + global_v3; } And my GDB session: (gdb) start Temporary breakpoint 1 at 0x40049a: file test.c, line 16. Starting program: /projects/gdb/tmp/static-syms/test Temporary breakpoint 1, main () at test.c:16 16 return use_them () + global_v2 + global_v3; (gdb) python print (gdb.lookup_static_symbol ('global_v1').value ()) 1 (gdb) python print (gdb.lookup_static_symbol ('global_v2').value ()) 2 (gdb) python print (gdb.lookup_static_symbol ('global_v3').value ()) Traceback (most recent call last): File "<string>", line 1, in <module> AttributeError: 'NoneType' object has no attribute 'value' Error while executing Python code. (gdb) Notice that despite being inside main, we see the file level 'global_v2' and completely miss the 'global_v3'. This is inline with the original behaviour of this function before I started messing with it. One source of confusion may have been that I added a call to lookup_symbol_in_static_block, this doesn't find a static symbol in a block, or the first static symbol between block and the global scope, but instead finds the static scope for a block and looks for a matching symbol in that block. The other source of confusion was my talking about 'print symbol_name'. You are correct that in the above test if I did 'print global_v2' I would see the static within main, so in that sense what I've implemented is _not_ like 'print symbol_name'. The only comparison I meant to draw with 'print symbol_name' was that if I do try to access 'global_v1' while in main I know I'll get the global_v1 from _this_ file, not a global_v1 from some other file. With the new 3rd patch a user can now from Python say, if I was in some other block, which static global would I see, which I think for a scripting interface is helpful. Then with the second patch the user can also find all static globals. However, anything you can find with lookup_static_symbol will _always_ be in the list returned by lookup_static_symbols. Hope this clears things up, Thanks, Andrew > > Christian > > > > > Thanks, > > Andrew > > > > --- > > > > commit 62d488878b467dd83a9abffc6dc3c67c2da82e85 > > Author: Andrew Burgess <andrew.burgess@embecosm.com> > > Date: Wed Oct 23 15:08:42 2019 +0100 > > > > gdb/python: New block parameter for gdb.lookup_static_symbol > > > > Adds a new block parameter to gdb.lookup_static_symbol. Currently > > gdb.lookup_static_symbol first looks in the global static scope of the > > current block for a matching symbol, and if non is found it then looks > > in all other global static scopes. > > > > The new block parameter for gdb.lookup_static_symbol allows the user > > to search the global static scope for some other block rather than the > > current block if they so desire. > > > > If the block parameter is no given, or is given as None, then GDB will > > search using the current block first (this matches the CLI behaviour). > > > > I added the block parameter to the middle of the parameter list, so > > the parameter order is 'symbol block domain', this matches the order > > of the other symbol lookup function that takes a block 'lookup_symbol' > > which also has the order 'symbol block domain'. I think changing the > > API like this is fine as the 'gdb.lookup_static_symbol' has not been > > in any previous GDB release, so there should be no existing user > > scripts that use this function. > > > > The documentation for gdb.lookup_static_symbol has been reordered so > > that the block parameter can be explained early on, and I've added > > some tests. > > > > gdb/ChangeLog: > > > > * python/py-symbol.c (gdbpy_lookup_static_symbol): Accept and > > handle a new block parameter. > > > > gdb/testsuite/ChangeLog: > > > > * gdb.python/py-symbol.exp: Add tests for passing a block > > parameter to gdb.lookup_static_symbol. > > > > gdb/doc/ChangeLog: > > > > * python.texi (Symbols In Python): Rewrite documentation for > > gdb.lookup_static_symbol, including adding a description of the > > new block parameter. > > > > Change-Id: I132a7f0934ba029c9f32058e9341a6c7cb975606 > > > > diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi > > index a30c8ae4f03..fe984a06b98 100644 > > --- a/gdb/doc/python.texi > > +++ b/gdb/doc/python.texi > > @@ -4853,31 +4853,41 @@ > > @end defun > > > > @findex gdb.lookup_static_symbol > > -@defun gdb.lookup_static_symbol (name @r{[}, domain@r{]}) > > -This function searches for a global symbol with static linkage by name. > > -The search scope can be restricted to by the domain argument. > > +@defun gdb.lookup_static_symbol (name @r{[}, block @r{[}, domain@r{]]}) > > +This function searches for a global symbol with static linkage by > > +name. > > > > @var{name} is the name of the symbol. It must be a string. > > -The optional @var{domain} argument restricts the search to the domain type. > > -The @var{domain} argument must be a domain constant defined in the @code{gdb} > > -module and described later in this chapter. > > - > > -The result is a @code{gdb.Symbol} object or @code{None} if the symbol > > -is not found. > > - > > -Note that this function will not find function-scoped static variables. To look > > -up such variables, iterate over the variables of the function's > > -@code{gdb.Block} and check that @code{block.addr_class} is > > -@code{gdb.SYMBOL_LOC_STATIC}. > > > > There can be multiple global symbols with static linkage with the same > > name. This function will only return the first matching symbol that > > it finds. Which symbol is found depends on where @value{GDBN} is > > currently stopped, as @value{GDBN} will first search for matching > > -symbols in the current object file, and then search all other object > > -files. If the application is not yet running then @value{GDBN} will > > -search all object files in the order they appear in the debug > > -information. > > +symbols in the global static scope of the current object file, and > > +then search all other object files. This corresponds to the behaviour > > +you would see from the CLI if you tried to print the symbol by name. > > + > > +If the application is not yet running then @value{GDBN} will search > > +all object files in the order they appear in the debug information. > > + > > +The optional @var{domain} argument restricts the search to the domain > > +type. The @var{domain} argument must be a domain constant defined in > > +the @code{gdb} module and described later in this chapter. > > + > > +The optional @var{block} argument can be used to change which global > > +static scope @value{GDBN} will search first. If @var{block} is not > > +given, or is passed the value @code{None} then @value{GDBN} will first > > +search the global static scope corresponding to the current block. If > > +@var{block} is passed a @code{gdb.Block} then @value{GDBN} will first > > +search the global static scope corresponding to the supplied block. > > + > > +The result is a @code{gdb.Symbol} object or @code{None} if the symbol > > +is not found. > > + > > +Note that this function will not find function-scoped static > > +variables. To look up such variables, iterate over the variables of > > +the function's @code{gdb.Block} and check that @code{block.addr_class} > > +is @code{gdb.SYMBOL_LOC_STATIC}. > > @end defun > > > > @findex gdb.lookup_global_symbol > > diff --git a/gdb/python/py-symbol.c b/gdb/python/py-symbol.c > > index 647c54b0a5b..24b3f6f4376 100644 > > --- a/gdb/python/py-symbol.c > > +++ b/gdb/python/py-symbol.c > > @@ -473,19 +473,20 @@ gdbpy_lookup_global_symbol (PyObject *self, PyObject *args, PyObject *kw) > > } > > > > /* Implementation of > > - gdb.lookup_static_symbol (name [, domain]) -> symbol or None. */ > > + gdb.lookup_static_symbol (name [, block] [, domain]) -> symbol or None. */ > > > > PyObject * > > gdbpy_lookup_static_symbol (PyObject *self, PyObject *args, PyObject *kw) > > { > > const char *name; > > int domain = VAR_DOMAIN; > > - static const char *keywords[] = { "name", "domain", NULL }; > > + static const char *keywords[] = { "name", "block", "domain", NULL }; > > struct symbol *symbol = NULL; > > + PyObject *block_obj = NULL; > > PyObject *sym_obj; > > > > - if (!gdb_PyArg_ParseTupleAndKeywords (args, kw, "s|i", keywords, &name, > > - &domain)) > > + if (!gdb_PyArg_ParseTupleAndKeywords (args, kw, "s|O|i", keywords, &name, > > + &block_obj, &domain)) > > return NULL; > > > > /* In order to find static symbols associated with the "current" object > > @@ -493,16 +494,22 @@ gdbpy_lookup_static_symbol (PyObject *self, PyObject *args, PyObject *kw) > > we can acquire a current block. If this fails however, then we still > > want to search all static symbols, so don't throw an exception just > > yet. */ > > - const struct block *block = NULL; > > - try > > - { > > - struct frame_info *selected_frame > > - = get_selected_frame (_("No frame selected.")); > > - block = get_frame_block (selected_frame, NULL); > > - } > > - catch (const gdb_exception &except) > > + const struct block *block = nullptr; > > + if (block_obj) > > + block = block_object_to_block (block_obj); > > + > > + if (block == nullptr) > > { > > - /* Nothing. */ > > + try > > + { > > + struct frame_info *selected_frame > > + = get_selected_frame (_("No frame selected.")); > > + block = get_frame_block (selected_frame, NULL); > > + } > > + catch (const gdb_exception &except) > > + { > > + /* Nothing. */ > > + } > > } > > > > try > > diff --git a/gdb/testsuite/gdb.python/py-symbol.exp b/gdb/testsuite/gdb.python/py-symbol.exp > > index ea41297f54f..0ffe07df5a8 100644 > > --- a/gdb/testsuite/gdb.python/py-symbol.exp > > +++ b/gdb/testsuite/gdb.python/py-symbol.exp > > @@ -87,6 +87,10 @@ if ![runto_main] then { > > > > global hex decimal > > > > +# Grab the value of $pc, we'll use this later. > > +set pc_val_file_1 [get_integer_valueof "\$pc" 0 \ > > + "get value of \$pc in main file"] > > + > > gdb_breakpoint [gdb_get_line_number "Block break here."] > > gdb_continue_to_breakpoint "Block break here." > > gdb_py_test_silent_cmd "python frame = gdb.selected_frame()" "Get Frame" 0 > > @@ -116,7 +120,18 @@ gdb_test "python print (func.addr_class == gdb.SYMBOL_LOC_BLOCK)" "True" "test f > > gdb_breakpoint "function_in_other_file" > > gdb_continue_to_breakpoint "function_in_other_file" > > gdb_test "python print (gdb.lookup_static_symbol ('rr').value ())" "99" \ > > - "print value of rr from other file" > > + "print value of rr from other file, don't pass a block value" > > +gdb_test "python print (gdb.lookup_static_symbol ('rr', None).value ())" "99" \ > > + "print value of rr from other file, pass block value of None" > > + > > +# Test gdb.lookup_static_symbol passing a block parameter > > +set pc_val_file_2 [get_integer_valueof "\$pc" 0 \ > > + "get \$pc in other file"] > > +gdb_test "python print (gdb.lookup_static_symbol ('rr', gdb.current_progspace ().block_for_pc (${pc_val_file_2})).value ())" "99" \ > > + "print value of rr from other file, pass block for other file" > > +gdb_test "python print (gdb.lookup_static_symbol ('rr', gdb.current_progspace ().block_for_pc (${pc_val_file_1})).value ())" "42" \ > > + "print value of rr from other file, pass block for main file" > > + > > gdb_test "python print (gdb.lookup_static_symbols ('rr')\[0\].value ())" "99" \ > > "print value of gdb.lookup_static_symbols ('rr')\[0\], from the other file" > > gdb_test "python print (gdb.lookup_static_symbols ('rr')\[1\].value ())" "42" \ > > @@ -131,7 +146,14 @@ gdb_py_test_silent_cmd "python frame = gdb.selected_frame()" "Get Frame" 0 > > # Check that we find the static sybol local to this file over the > > # static symbol from the second source file. > > gdb_test "python print (gdb.lookup_static_symbol ('rr').value ())" "42" \ > > - "print value of rr from main file" > > + "print value of rr from main file, passing no block parameter" > > +gdb_test "python print (gdb.lookup_static_symbol ('rr', None).value ())" "42" \ > > + "print value of rr from main file, passing None block parameter" > > +gdb_test "python print (gdb.lookup_static_symbol ('rr', gdb.current_progspace ().block_for_pc (${pc_val_file_2})).value ())" "99" \ > > + "print value of rr from main file, pass block for other file" > > +gdb_test "python print (gdb.lookup_static_symbol ('rr', gdb.current_progspace ().block_for_pc (${pc_val_file_1})).value ())" "42" \ > > + "print value of rr from main file, pass block for main file" > > + > > gdb_test "python print (gdb.lookup_static_symbols ('rr')\[0\].value ())" "99" \ > > "print value of gdb.lookup_static_symbols ('rr')\[0\], from the main file" > > gdb_test "python print (gdb.lookup_static_symbols ('rr')\[1\].value ())" "42" \
On 2019-11-01 7:53 a.m., Andrew Burgess wrote: >> I'm sorry, I think I was a bit confused when I wrote that. Here's what >> I was thinking about -- with your change to make lookup_static_symbol >> produce the same result as "print var", it will also find block-level >> statics. However, lookup_static_symbols only looks at file-level >> static variables, which means that lookup_static_symbol can find a >> variable that's not in lookup_static_symbols, which seems confusing to >> users. My suggestion to give it a block to start in didn't really make >> sense, I think, but it would be good to think about that a bit more? > > This is not correct, both lookup_static_symbol AND > lookup_static_symbols BOTH only lookup file level static globals. > > [ SIDE-ISSUE : The name for both of these is obviously a possible > sauce of confusion, maybe before this function makes it into a > release we should consider renaming it/them? How about > lookup_static_global(s) ? ] I would at least make sure the naming is consistent with gdb.lookup_global_symbol, so have the _symbol(s) suffix. So, lookup_static_global_symbol(s). I don't think that lookup_static_symbols is particularly confusing. As a user, I don't think I would expect it to return static symbols from local scopes. I think what makes lookup_static_symbol ambiguous is that we're considering making it take a block as parameter. Then, I agree, a user could think that it will find static symbols from local scopes. But AFAIK, we're considering passing a block to lookup_static_symbol only because of a current shortcoming in the API, that we don't have an object type representing a compilation unit. If lookup_static_symbol accepted a compilation unit object instead, then I don't think there would be a similar confusion (especially that it is singular, and returns a single symbol). Would it be an option to not add lookup_static_symbol for now, and instead work on having a type representing compilation units, and then think about introducing lookup_static_symbol again? Christian, can you achieve what you wanted using lookup_static_symbols plus some filtering instead? > Here's a demo session using the above 3 patches, the test file is: > > static int global_v1 = 1; > static int global_v2 = 2; > > int > use_them () > { > return global_v1 + global_v2; > } > > int > main () > { > static int global_v2 = 3; > static int global_v3 = 4; > > return use_them () + global_v2 + global_v3; > } > > And my GDB session: > > (gdb) start > Temporary breakpoint 1 at 0x40049a: file test.c, line 16. > Starting program: /projects/gdb/tmp/static-syms/test > > Temporary breakpoint 1, main () at test.c:16 > 16 return use_them () + global_v2 + global_v3; > (gdb) python print (gdb.lookup_static_symbol ('global_v1').value ()) > 1 > (gdb) python print (gdb.lookup_static_symbol ('global_v2').value ()) > 2 > (gdb) python print (gdb.lookup_static_symbol ('global_v3').value ()) > Traceback (most recent call last): > File "<string>", line 1, in <module> > AttributeError: 'NoneType' object has no attribute 'value' > Error while executing Python code. > (gdb) > > Notice that despite being inside main, we see the file level > 'global_v2' and completely miss the 'global_v3'. This is inline with > the original behaviour of this function before I started messing with > it. > > One source of confusion may have been that I added a call to > lookup_symbol_in_static_block, this doesn't find a static symbol in a > block, or the first static symbol between block and the global scope, > but instead finds the static scope for a block and looks for a > matching symbol in that block. > > The other source of confusion was my talking about 'print > symbol_name'. You are correct that in the above test if I did 'print > global_v2' I would see the static within main, so in that sense what > I've implemented is _not_ like 'print symbol_name'. The only > comparison I meant to draw with 'print symbol_name' was that if I do > try to access 'global_v1' while in main I know I'll get the global_v1 > from _this_ file, not a global_v1 from some other file. > > With the new 3rd patch a user can now from Python say, if I was in > some other block, which static global would I see, which I think for a > scripting interface is helpful. Then with the second patch the user > can also find all static globals. However, anything you can find with > lookup_static_symbol will _always_ be in the list returned by > lookup_static_symbols. Ok, that's the behavior I expected (to not find static local symbols), thanks for clearing that up. Simon
* Simon Marchi <simark@simark.ca> [2019-11-01 09:55:07 -0400]: > On 2019-11-01 7:53 a.m., Andrew Burgess wrote: > >> I'm sorry, I think I was a bit confused when I wrote that. Here's what > >> I was thinking about -- with your change to make lookup_static_symbol > >> produce the same result as "print var", it will also find block-level > >> statics. However, lookup_static_symbols only looks at file-level > >> static variables, which means that lookup_static_symbol can find a > >> variable that's not in lookup_static_symbols, which seems confusing to > >> users. My suggestion to give it a block to start in didn't really make > >> sense, I think, but it would be good to think about that a bit more? > > > > This is not correct, both lookup_static_symbol AND > > lookup_static_symbols BOTH only lookup file level static globals. > > > > [ SIDE-ISSUE : The name for both of these is obviously a possible > > sauce of confusion, maybe before this function makes it into a > > release we should consider renaming it/them? How about > > lookup_static_global(s) ? ] > > I would at least make sure the naming is consistent with gdb.lookup_global_symbol, > so have the _symbol(s) suffix. So, lookup_static_global_symbol(s). > > I don't think that lookup_static_symbols is particularly confusing. As a user, I > don't think I would expect it to return static symbols from local scopes. > > I think what makes lookup_static_symbol ambiguous is that we're considering making > it take a block as parameter. Then, I agree, a user could think that it will find > static symbols from local scopes. > > But AFAIK, we're considering passing a block to lookup_static_symbol only because > of a current shortcoming in the API, that we don't have an object type > representing a compilation unit. If lookup_static_symbol accepted a compilation > unit object instead, then I don't think there would be a similar confusion > (especially that it is singular, and returns a single symbol). > > Would it be an option to not add lookup_static_symbol for now, and instead work > on having a type representing compilation units, and then think about introducing > lookup_static_symbol again? Christian, can you achieve what you wanted using > lookup_static_symbols plus some filtering instead? 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? Thanks, Andrew > > > Here's a demo session using the above 3 patches, the test file is: > > > > static int global_v1 = 1; > > static int global_v2 = 2; > > > > int > > use_them () > > { > > return global_v1 + global_v2; > > } > > > > int > > main () > > { > > static int global_v2 = 3; > > static int global_v3 = 4; > > > > return use_them () + global_v2 + global_v3; > > } > > > > And my GDB session: > > > > (gdb) start > > Temporary breakpoint 1 at 0x40049a: file test.c, line 16. > > Starting program: /projects/gdb/tmp/static-syms/test > > > > Temporary breakpoint 1, main () at test.c:16 > > 16 return use_them () + global_v2 + global_v3; > > (gdb) python print (gdb.lookup_static_symbol ('global_v1').value ()) > > 1 > > (gdb) python print (gdb.lookup_static_symbol ('global_v2').value ()) > > 2 > > (gdb) python print (gdb.lookup_static_symbol ('global_v3').value ()) > > Traceback (most recent call last): > > File "<string>", line 1, in <module> > > AttributeError: 'NoneType' object has no attribute 'value' > > Error while executing Python code. > > (gdb) > > > > Notice that despite being inside main, we see the file level > > 'global_v2' and completely miss the 'global_v3'. This is inline with > > the original behaviour of this function before I started messing with > > it. > > > > One source of confusion may have been that I added a call to > > lookup_symbol_in_static_block, this doesn't find a static symbol in a > > block, or the first static symbol between block and the global scope, > > but instead finds the static scope for a block and looks for a > > matching symbol in that block. > > > > The other source of confusion was my talking about 'print > > symbol_name'. You are correct that in the above test if I did 'print > > global_v2' I would see the static within main, so in that sense what > > I've implemented is _not_ like 'print symbol_name'. The only > > comparison I meant to draw with 'print symbol_name' was that if I do > > try to access 'global_v1' while in main I know I'll get the global_v1 > > from _this_ file, not a global_v1 from some other file. > > > > With the new 3rd patch a user can now from Python say, if I was in > > some other block, which static global would I see, which I think for a > > scripting interface is helpful. Then with the second patch the user > > can also find all static globals. However, anything you can find with > > lookup_static_symbol will _always_ be in the list returned by > > lookup_static_symbols. > > Ok, that's the behavior I expected (to not find static local symbols), thanks > for clearing that up. > > Simon
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? But it's Christian who initially wanted to add these functions, he probably had a particular use case in mind. It would be up to him to say if that covers that use case or not. Simon
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. My personal use case was & is still addressed, I just wanted a way to find variables like these: https://cs.chromium.org/chromium/src/content/renderer/render_frame_impl.cc?q=g_frame_map&sq=package:chromium&g=0&l=332 (^ in an anonymous namespace) ideally also: https://cs.chromium.org/chromium/src/ui/accessibility/ax_tree_manager_map.cc?type=cs&sq=package:chromium&g=0&l=17 (static variable in a function) But I do have a fallback to gdb.lookup_symbol, so that one works too, though less efficiently. Even with a CU API, this might be difficult (maybe? depending how easy it is to find a specific function from a CU) Christian
* 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, Andrew
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
* Christian Biesinger <cbiesinger@google.com> [2019-11-10 16:36:52 -0600]: > 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) I don't think that's a crazy idea, but I don't plan to write one right now. My interest in this area started when I was auditing how the GDB function lookup_static_function (the one in symtab.c) was used, and I felt that the way it was used in the python code wasn't quite right. I don't have any specific use cases to address. We can always add extra API methods later if/when there's a need for them without breaking backward compatibility, so I'm happy to leave this for now. Thanks, Andrew
On Mon, Nov 11, 2019 at 8:27 AM Andrew Burgess <andrew.burgess@embecosm.com> wrote: > > 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) > > I don't think that's a crazy idea, but I don't plan to write one right > now. > > My interest in this area started when I was auditing how the GDB > function lookup_static_function (the one in symtab.c) was used, and I > felt that the way it was used in the python code wasn't quite right. > I don't have any specific use cases to address. > > We can always add extra API methods later if/when there's a need for > them without breaking backward compatibility, so I'm happy to leave > this for now. OK, sounds good. Christian
diff --git a/gdb/doc/python.texi b/gdb/doc/python.texi index a30c8ae4f03..fe984a06b98 100644 --- a/gdb/doc/python.texi +++ b/gdb/doc/python.texi @@ -4853,31 +4853,41 @@ @end defun @findex gdb.lookup_static_symbol -@defun gdb.lookup_static_symbol (name @r{[}, domain@r{]}) -This function searches for a global symbol with static linkage by name. -The search scope can be restricted to by the domain argument. +@defun gdb.lookup_static_symbol (name @r{[}, block @r{[}, domain@r{]]}) +This function searches for a global symbol with static linkage by +name. @var{name} is the name of the symbol. It must be a string. -The optional @var{domain} argument restricts the search to the domain type. -The @var{domain} argument must be a domain constant defined in the @code{gdb} -module and described later in this chapter. - -The result is a @code{gdb.Symbol} object or @code{None} if the symbol -is not found. - -Note that this function will not find function-scoped static variables. To look -up such variables, iterate over the variables of the function's -@code{gdb.Block} and check that @code{block.addr_class} is -@code{gdb.SYMBOL_LOC_STATIC}. There can be multiple global symbols with static linkage with the same name. This function will only return the first matching symbol that it finds. Which symbol is found depends on where @value{GDBN} is currently stopped, as @value{GDBN} will first search for matching -symbols in the current object file, and then search all other object -files. If the application is not yet running then @value{GDBN} will -search all object files in the order they appear in the debug -information. +symbols in the global static scope of the current object file, and +then search all other object files. This corresponds to the behaviour +you would see from the CLI if you tried to print the symbol by name. + +If the application is not yet running then @value{GDBN} will search +all object files in the order they appear in the debug information. + +The optional @var{domain} argument restricts the search to the domain +type. The @var{domain} argument must be a domain constant defined in +the @code{gdb} module and described later in this chapter. + +The optional @var{block} argument can be used to change which global +static scope @value{GDBN} will search first. If @var{block} is not +given, or is passed the value @code{None} then @value{GDBN} will first +search the global static scope corresponding to the current block. If +@var{block} is passed a @code{gdb.Block} then @value{GDBN} will first +search the global static scope corresponding to the supplied block. + +The result is a @code{gdb.Symbol} object or @code{None} if the symbol +is not found. + +Note that this function will not find function-scoped static +variables. To look up such variables, iterate over the variables of +the function's @code{gdb.Block} and check that @code{block.addr_class} +is @code{gdb.SYMBOL_LOC_STATIC}. @end defun @findex gdb.lookup_global_symbol diff --git a/gdb/python/py-symbol.c b/gdb/python/py-symbol.c index 647c54b0a5b..24b3f6f4376 100644 --- a/gdb/python/py-symbol.c +++ b/gdb/python/py-symbol.c @@ -473,19 +473,20 @@ gdbpy_lookup_global_symbol (PyObject *self, PyObject *args, PyObject *kw) } /* Implementation of - gdb.lookup_static_symbol (name [, domain]) -> symbol or None. */ + gdb.lookup_static_symbol (name [, block] [, domain]) -> symbol or None. */ PyObject * gdbpy_lookup_static_symbol (PyObject *self, PyObject *args, PyObject *kw) { const char *name; int domain = VAR_DOMAIN; - static const char *keywords[] = { "name", "domain", NULL }; + static const char *keywords[] = { "name", "block", "domain", NULL }; struct symbol *symbol = NULL; + PyObject *block_obj = NULL; PyObject *sym_obj; - if (!gdb_PyArg_ParseTupleAndKeywords (args, kw, "s|i", keywords, &name, - &domain)) + if (!gdb_PyArg_ParseTupleAndKeywords (args, kw, "s|O|i", keywords, &name, + &block_obj, &domain)) return NULL; /* In order to find static symbols associated with the "current" object @@ -493,16 +494,22 @@ gdbpy_lookup_static_symbol (PyObject *self, PyObject *args, PyObject *kw) we can acquire a current block. If this fails however, then we still want to search all static symbols, so don't throw an exception just yet. */ - const struct block *block = NULL; - try - { - struct frame_info *selected_frame - = get_selected_frame (_("No frame selected.")); - block = get_frame_block (selected_frame, NULL); - } - catch (const gdb_exception &except) + const struct block *block = nullptr; + if (block_obj) + block = block_object_to_block (block_obj); + + if (block == nullptr) { - /* Nothing. */ + try + { + struct frame_info *selected_frame + = get_selected_frame (_("No frame selected.")); + block = get_frame_block (selected_frame, NULL); + } + catch (const gdb_exception &except) + { + /* Nothing. */ + } } try diff --git a/gdb/testsuite/gdb.python/py-symbol.exp b/gdb/testsuite/gdb.python/py-symbol.exp index ea41297f54f..0ffe07df5a8 100644 --- a/gdb/testsuite/gdb.python/py-symbol.exp +++ b/gdb/testsuite/gdb.python/py-symbol.exp @@ -87,6 +87,10 @@ if ![runto_main] then { global hex decimal +# Grab the value of $pc, we'll use this later. +set pc_val_file_1 [get_integer_valueof "\$pc" 0 \ + "get value of \$pc in main file"] + gdb_breakpoint [gdb_get_line_number "Block break here."] gdb_continue_to_breakpoint "Block break here." gdb_py_test_silent_cmd "python frame = gdb.selected_frame()" "Get Frame" 0 @@ -116,7 +120,18 @@ gdb_test "python print (func.addr_class == gdb.SYMBOL_LOC_BLOCK)" "True" "test f gdb_breakpoint "function_in_other_file" gdb_continue_to_breakpoint "function_in_other_file" gdb_test "python print (gdb.lookup_static_symbol ('rr').value ())" "99" \ - "print value of rr from other file" + "print value of rr from other file, don't pass a block value" +gdb_test "python print (gdb.lookup_static_symbol ('rr', None).value ())" "99" \ + "print value of rr from other file, pass block value of None" + +# Test gdb.lookup_static_symbol passing a block parameter +set pc_val_file_2 [get_integer_valueof "\$pc" 0 \ + "get \$pc in other file"] +gdb_test "python print (gdb.lookup_static_symbol ('rr', gdb.current_progspace ().block_for_pc (${pc_val_file_2})).value ())" "99" \ + "print value of rr from other file, pass block for other file" +gdb_test "python print (gdb.lookup_static_symbol ('rr', gdb.current_progspace ().block_for_pc (${pc_val_file_1})).value ())" "42" \ + "print value of rr from other file, pass block for main file" + gdb_test "python print (gdb.lookup_static_symbols ('rr')\[0\].value ())" "99" \ "print value of gdb.lookup_static_symbols ('rr')\[0\], from the other file" gdb_test "python print (gdb.lookup_static_symbols ('rr')\[1\].value ())" "42" \ @@ -131,7 +146,14 @@ gdb_py_test_silent_cmd "python frame = gdb.selected_frame()" "Get Frame" 0 # Check that we find the static sybol local to this file over the # static symbol from the second source file. gdb_test "python print (gdb.lookup_static_symbol ('rr').value ())" "42" \ - "print value of rr from main file" + "print value of rr from main file, passing no block parameter" +gdb_test "python print (gdb.lookup_static_symbol ('rr', None).value ())" "42" \ + "print value of rr from main file, passing None block parameter" +gdb_test "python print (gdb.lookup_static_symbol ('rr', gdb.current_progspace ().block_for_pc (${pc_val_file_2})).value ())" "99" \ + "print value of rr from main file, pass block for other file" +gdb_test "python print (gdb.lookup_static_symbol ('rr', gdb.current_progspace ().block_for_pc (${pc_val_file_1})).value ())" "42" \ + "print value of rr from main file, pass block for main file" + gdb_test "python print (gdb.lookup_static_symbols ('rr')\[0\].value ())" "99" \ "print value of gdb.lookup_static_symbols ('rr')\[0\], from the main file" gdb_test "python print (gdb.lookup_static_symbols ('rr')\[1\].value ())" "42" \