Re: question about expand_symtabs_matching()

[Tom Tromey <tom@tromey.com>]

Hannes> This is probably a stupid question.

Not at all.

Hannes> In gdb/linespec.c:1146 is this call:
Hannes>       if (objfile->sf)
Hannes>         objfile->sf->qf->expand_symtabs_matching (objfile,
Hannes>                                                   NULL,
Hannes>                                                   lookup_name,
Hannes>                                                   NULL, NULL,
Hannes>                                                   search_domain);
Hannes> What exactly is this call doing, since none of the 3 callback functions is used?

gdb first scans debug symbols to create "partial symbol tables" (or in
some cases it uses the "gdb index").

These don't contain much information, so in order to actually do much
with the symbols, the relevant psymtabs must be expanded into full
symbol tables.

This call is expanding all the partial symbol tables that match
lookup_name and search_domain.  The loop that comes after this actually
does the work of the function, by looking only at expanded symbol
tables.

Hannes> This is slowing gdb down quite a lot if you have pending breakpoints, and are 
Hannes> loading/unloading many shared libraries.

Yeah.  gdb does too much work when re-evaluating breakpoint locations.

For example, it seems to me that when re-evaluating a breakpoint
location, there's no reason to search an objfile again -- the results
can't have changed.  There are various ways this could be tackled but I
suppose the basic idea is to cache the results somewhere.

Hannes> When I removed it, I couldn't see any different behavior (other than being faster).

I think it would make a difference if the inferior dlopen()d a library
and the library had a new location for an existing breakpoint.

Tom