This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH][PR/24474] Make gdb.lookup_static_symbol also check the STATIC_SCOPE
- From: Simon Marchi <simark at simark dot ca>
- To: Christian Biesinger <cbiesinger at google dot com>
- Cc: Christian Biesinger via gdb-patches <gdb-patches at sourceware dot org>
- Date: Fri, 26 Jul 2019 18:43:10 -0400
- Subject: Re: [PATCH][PR/24474] Make gdb.lookup_static_symbol also check the STATIC_SCOPE
- References: <firstname.lastname@example.org> <email@example.com> <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'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
Yes, and it's always possible to add parameters after if needed since
I will send a new patch with this in a moment.