Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <andrew.burgess@embecosm.com>
To: Simon Marchi <simark@simark.ca>
Cc: Christian Biesinger <cbiesinger@google.com>,
	gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH] gdb/python: Introduce gdb.lookup_all_static_symbols
Date: Thu, 24 Oct 2019 16:53:00 -0000	[thread overview]
Message-ID: <20191024165306.GM4962@embecosm.com> (raw)
In-Reply-To: <4582382d-b58a-8fa8-9478-168de34e2a82@simark.ca>

* 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


  reply	other threads:[~2019-10-24 16:53 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-23 16:46 [PATCH] gdb/python: smarter symbol lookup for gdb.lookup_static_symbol Andrew Burgess
2019-09-23 17:18 ` Eli Zaretskii
2019-10-08 11:07   ` [PATCHv2] " Andrew Burgess
2019-10-08 12:01     ` Eli Zaretskii
2019-10-08 16:01     ` Christian Biesinger via gdb-patches
2019-10-15 14:15       ` Andrew Burgess
2019-10-15 16:46         ` [PATCH] gdb/python: Introduce gdb.lookup_all_static_symbols Andrew Burgess
2019-10-15 17:07           ` Eli Zaretskii
2019-10-23 19:15             ` Andrew Burgess
2019-10-24  2:31               ` Eli Zaretskii
2019-10-15 19:28           ` Simon Marchi
2019-10-15 23:32             ` Andrew Burgess
2019-10-21 22:37             ` Christian Biesinger via gdb-patches
2019-10-23 19:14               ` Andrew Burgess
2019-10-24  3:11                 ` Simon Marchi
2019-10-24 16:53                   ` Andrew Burgess [this message]
2019-10-28  5:08                 ` Christian Biesinger via gdb-patches
2019-11-01 11:53                   ` Andrew Burgess
2019-11-01 13:55                     ` Simon Marchi
2019-11-04 17:12                       ` Andrew Burgess
2019-11-04 18:28                         ` Simon Marchi
2019-11-09  6:23                           ` Christian Biesinger via gdb-patches
2019-11-10 22:27                             ` Andrew Burgess
2019-11-10 22:37                               ` Christian Biesinger via gdb-patches
2019-11-11 16:27                                 ` Andrew Burgess
2019-11-11 16:31                                   ` Christian Biesinger via gdb-patches
2019-10-16 21:53         ` [PATCHv2] gdb/python: smarter symbol lookup for gdb.lookup_static_symbol Christian Biesinger via gdb-patches

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191024165306.GM4962@embecosm.com \
    --to=andrew.burgess@embecosm.com \
    --cc=cbiesinger@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=simark@simark.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox