[PATCH] [gdb/symtab] Skip local variables in cooked index

[Tom de Vries]

On 10/16/24 22:23, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
> 
> Tom> +      if (!abbrev->interesting
> Tom> +	  || (abbrev->tag == DW_TAG_variable && parent_entry != nullptr
> Tom> +	      && parent_entry->tag == DW_TAG_subprogram))
> 
> I think when recursing into a DW_TAG_subprogram, we're only really
> looking for other DW_TAG_subprogram entries.  Everything else can be
> excluded.
> 

OK, let me try that approach in a v2.

> If linespec and the parsers were improved a little, we could avoid
> recursing here entirely.  I wonder if that's possible today.
> 

I disabled this bit:
...
             case DW_TAG_subprogram:
#if 0
               if ((m_language == language_fortran
                    || m_language == language_ada)
                   && this_entry != nullptr)
                 {
                   info_ptr = recurse (reader, info_ptr, this_entry, true);
                   continue;
                 }
#endif
               break;
             }
...
and ran into problems in test-cases gdb.ada/bp_reset.exp and 
gdb.fortran/nested-funcs-2.exp.  In both cases, what starts failing is 
using the unqualified name of the nested function, outside the declaring 
scope (FWIW, I haven't tried inside):
...
(gdb) file gdb.ada/bp_reset/foo^M
Reading symbols from gdb.ada/bp_reset/foo...^M
(gdb) break nested_sub^M
Function "nested_sub" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.ada/bp_reset.exp: break nested_sub (got interactive prompt)
...
and:
...
(gdb) file /gdb.fortran/nested-funcs-2/nested-funcs-2^M
Reading symbols from gdb.fortran/nested-funcs-2/nested-funcs-2...^M
(gdb) break increment^M
Function "increment" not defined.^M
Make breakpoint pending on future shared library load? (y or [n]) n^M
(gdb) FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: \
   nest_prefix=0: before start: gdb_breakpoint: \
   set breakpoint at increment
...

In both cases, using the qualified name instead: foo.nested_sub and 
contains_keyword::increment worked fine.

So, if using the unqualified name outside the declaring scope is 
supported behaviour, then I don't see how we can handle this without 
recursing into the DW_TAG_subprogram.

> Possibly we'd want to let "print 'some_function()'::local_static_variable"
> work, but if we did that I'd definitely lobby for parser support and not
> symbol table entries.

At least for C, AFAICT for that's supported already:
...
$ cat test.c
int
main (void)
{
   static int local_static_variable = 1;
   return local_static_variable;
}
$ gcc -g test.c
$ gdb -q -batch a.out -ex "print 'main'::local_static_variable"
$1 = 1
...
without corresponding entries in the cooked index.

Thanks,
- Tom