[Bug symtab/30736] New: [gdb/symtab] Result of cooked_index_functions::expand_symtabs_matching depends on expansion state

[Bug symtab/30736] New: [gdb/symtab] Result of cooked_index_functions::expand_symtabs_matching depends on expansion state

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30736

            Bug ID: 30736
           Summary: [gdb/symtab] Result of
                    cooked_index_functions::expand_symtabs_matching
                    depends on expansion state
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

I was looking at cooked_index_functions::expand_symtabs_matching and came
across:
...
         /* No need to consider symbols from expanded CUs.  */
          if (per_objfile->symtab_set_p (entry->per_cu))
            continue;
...
and had trouble understanding this.

My understanding of how a lookup should work is:
- find the set of relevant symtabs
- make sure they're expanded
- do the lookup in the set of relevant expanded symtabs

Then, there are roughly two modes of lookup:
- find the first match, and
- find all matches

The code snippet above fits well with the "find all matches" approach.

If we're iterating to ensure all relevant symtabs are expanded, and a symtab is
already expanded, no need to consider it further, regardless of whether it's
relevant or not.

But if we're iterating to find the first relevant symtab and make sure it's
expanded, the code snippet make sure that subsequent lookups will find a
different first match.

This is similar to PR25857.

If we apply the tentative fix for PR25857 (reverse order in
lookup_symbol_in_objfile), we can demonstrate this PR using a similar
test-case:
...
$ cat test.c
static int aaa = 2;

int
main (void)
{
  return 0;
}
$ cat test-2.c
static int aaa = 1;
$ gcc -g test.c test-2.c
$ gdb -q -batch -iex "set trace-commands on" a.out \
    -ex "print aaa" \
    -ex "maint info symtabs" \
    -ex "maint flush symbol-cache" \
    -ex "print aaa" \
    -ex "maint info symtabs"
+print aaa
$1 = 2
+maint info symtabs
{ objfile /data/vries/gdb/a.out ((struct objfile *) 0x4b451f0)
  { ((struct compunit_symtab *) 0x4b3d280)
    debugformat DWARF 4
    producer GNU C11 7.5.0 -mtune=generic -march=x86-64 -g
    name test.c
    dirname /home/vries/gdb
    blockvector ((struct blockvector *) 0x4b3d760)
    user ((struct compunit_symtab *) (null))
        { symtab test.c ((struct symtab *) 0x4b3d300)
          fullname (null)
          linetable ((struct linetable *) 0x4b3d790)
        }
  }
}
+maint flush symbol-cache
+print aaa
$2 = 1
+maint info symtabs
{ objfile /data/vries/gdb/a.out ((struct objfile *) 0x4b451f0)
  { ((struct compunit_symtab *) 0x4b3d800)
    debugformat DWARF 4
    producer GNU C11 7.5.0 -mtune=generic -march=x86-64 -g
    name test-2.c
    dirname /home/vries/gdb
    blockvector ((struct blockvector *) 0x4b3db00)
    user ((struct compunit_symtab *) (null))
        { symtab test-2.c ((struct symtab *) 0x4b3d880)
          fullname (null)
          linetable ((struct linetable *) 0x0)
        }
  }
  { ((struct compunit_symtab *) 0x4b3d280)
    debugformat DWARF 4
    producer GNU C11 7.5.0 -mtune=generic -march=x86-64 -g
    name test.c
    dirname /home/vries/gdb
    blockvector ((struct blockvector *) 0x4b3d760)
    user ((struct compunit_symtab *) (null))
        { symtab test.c ((struct symtab *) 0x4b3d300)
          fullname (null)
          linetable ((struct linetable *) 0x4b3d790)
        }
  }
}
...

In other words:
- lookup aaa is done, symtab test.c matches and is expanded
- value of aaa in test.c is printed
- symbol-cache is flushed (otherwise we're guaranteed to have the same
  value, and no actual lookup is done)
- another lookup of aaa is done, symtab test.c is skipped because it's already
  expanded, symtab test-2.c matches and is expanded
- value of aaa in test-2.c is printed

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30736] [gdb/symtab] Result of cooked_index_functions::expand_symtabs_matching depends on expansion state

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30736

--- Comment #1 from Tom de Vries <vries at gcc dot gnu.org> ---
The function as is works as documented.

If the only side effect of the function is symtab expansion, then there's not a
problem.

The problem is really its use in combination with search_one_symtab as
expansion_notify function.

-- 
You are receiving this mail because:
You are on the CC list for the bug.