Re: [PATCH v2 10/28] Have expand_symtabs_matching work for already-expanded CUs

Simon Marchi
2025-04-23T15:54:35Z

On 2025-04-02 19:45, Tom Tromey wrote:
> Currently, gdb will search the already-expanded symtabs in one loop,
> and then also expand matching symtabs in another loop. However, this
> is somewhat inefficient -- when searching the already-expanded
> symtabs, all such symtabs are examined. However, the various "quick"
> implementations already know which subset of symtabs might have a
> match.
>
> This changes the contract of expand_symtabs_matching to also call the
> callback for an already-expanded symtab. With this change, the number
> of searched symtabs should sometimes be reduced. This also cuts down
> on the amount of redundant code.

Not particularly important, but I'm not sure I understand how this patch
alone would result in fewer symtabs being searched. I understand that
it's a step towards the ultimate goal of this series, but I suppose you
need the changes to the symbol lookup functions (that come later in this
series) to reduce the number of searched symtabs?

I don't know if it comes later in the series, but it would be good to
do some renaming, because "expand matching symtabs" is no longer
accurate. It's more like "find matching symtab". That can be done later
of course.

> @@ -4211,6 +4223,12 @@ load_full_comp_unit (dwarf2_per_cu *this_cu, dwarf2_per_objfile *per_objfile,
> if (reader.is_dummy ())
> return;
>
> + /* We always need the file names filled in so that
> + expand_symtabs_matching can match filenames. It's convenient to
> + do this here. */
> + if (!this_cu->files_read)
> + dw2_get_file_names_reader (reader.cu (), reader.top_level_die ());

In other spots, this is initialized lazily when something calls
dw2_get_file_names. Why would it not work with expand_symtabs_matching?

Simon