Re: question about expand_symtabs_matching()

Am Mittwoch, 27. Februar 2019, 22:25:52 MEZ hat Tom Tromey <[email protected]> Folgendes geschrieben:

> Hannes> This is probably a stupid question.
> 
> Not at all.
Thanks for the fast reply.

> 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.

Yeah, I was wondering about that too, anytime a library is loaded all is redone from scratch.

And in case a shared library is unloaded, I would have thought that you could just removeall breakpoints in the address range of the shared library.

> 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.

I think I understand now basically why this is done.

What if I have a simple breakpoint like 'break some-file.c:123', is there even any
symbol that can be expanded with expand_symtabs_matching()?


RegardsHannes Domani