Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simark@simark.ca>
To: Christian Biesinger <cbiesinger@google.com>
Cc: Christian Biesinger via gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH][PR/24474] Make gdb.lookup_static_symbol also check the STATIC_SCOPE
Date: Fri, 26 Jul 2019 22:43:00 -0000	[thread overview]
Message-ID: <c3ec41a563c8e681b665a98debd03842@simark.ca> (raw)
In-Reply-To: <CAPTJ0XEh08SX1sAR4UBuFpPzP=yYf_G4U9PV+PYNgcy+V6AZuQ@mail.gmail.com>

On 2019-07-26 18:04, Christian Biesinger wrote:
> Thanks for your response! I have started implementing this and
> concluded that I would prefer not to add a block argument with this
> behavior to lookup_static_symbol:
> - If I add it with the behavior you suggest, this will be very
> confusing to use because it won't find function-local static variables
> (they are not part of the static block)

Agreed, it would be a bit confusing to pass a block to a 'lookup' 
function, and have the search actually done in another block.

> - It does not add new functionality. You can already access static
> symbols if you have a block: [sym for sym in block if sym.addr_class
> == gdb.SYMBOL_LOC_STATIC]. And you can already do that in a function's
> static block too, using block.static_block.

I agree.

> - I'd be happy to add a patch that adds makes block['foo'] work, in
> addition to the currently-existing iteration

That is a separate issue, but yeah, if blocks can be seen as containers 
of symbols, and symbol names are guaranteed to be unique within a block, 
then it sounds like it would be handy.

> 
> Conversely, lookup_static_symbol without a block does add new 
> functionality.

Yes, and it's always possible to add parameters after if needed since 
it's Python.

> I will send a new patch with this in a moment.

Thanks,

Simon


  parent reply	other threads:[~2019-07-26 22:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-05  1:24 Christian Biesinger via gdb-patches
2019-06-18 20:15 ` Christian Biesinger via gdb-patches
2019-07-08 22:05 ` [PING] " Christian Biesinger via gdb-patches
2019-07-15 16:52   ` Christian Biesinger via gdb-patches
2019-07-16  3:28 ` Simon Marchi
2019-07-26 22:05   ` Christian Biesinger via gdb-patches
2019-07-26 22:23     ` [PATCH v2] [PR/24474] Add gdb.lookup_static_symbol to the python API Christian Biesinger via gdb-patches
2019-07-30  1:14       ` Simon Marchi
2019-07-30  1:35         ` [PATCH v3] " Christian Biesinger via gdb-patches
2019-07-30  1:50           ` Simon Marchi
2019-07-30  1:59             ` [PATCH v4] " Christian Biesinger via gdb-patches
2019-07-30 15:41               ` Christian Biesinger via gdb-patches
2019-07-30 15:57                 ` Eli Zaretskii
2019-07-30 16:01                   ` Christian Biesinger via gdb-patches
2019-07-26 22:43     ` Simon Marchi [this message]
2019-08-01 19:05   ` [PATCH][PR/24474] Make gdb.lookup_static_symbol also check the STATIC_SCOPE 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=c3ec41a563c8e681b665a98debd03842@simark.ca \
    --to=simark@simark.ca \
    --cc=cbiesinger@google.com \
    --cc=gdb-patches@sourceware.org \
    /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