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

Simon Marchi
2019-11-01T13:55:13Z

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