This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: question about expand_symtabs_matching()
- From: "Hannes Domani via gdb" <gdb at sourceware dot org>
- To: GDB Development <gdb at sourceware dot org>
- Date: Thu, 28 Feb 2019 11:32:45 +0000 (UTC)
- Subject: Re: question about expand_symtabs_matching()
- References: <183519794.10360727.1551304006549.ref@mail.yahoo.com> <183519794.10360727.1551304006549@mail.yahoo.com> <87h8copz0d.fsf@tromey.com>
- Reply-to: Hannes Domani <ssbssa at yahoo dot de>
Am Donnerstag, 28. Februar 2019, 00:55:50 MEZ hat Tom Tromey <tom@tromey.com> Folgendes geschrieben:
> >>>>> "Hannes" == Hannes Domani via gdb <gdb@sourceware.org> writes:
>
> Hannes> And in case a shared library is unloaded, I would have thought
> Hannes> that you could just removeall breakpoints in the address range
> Hannes> of the shared library.
>
> Yes.
>
> At one point we had discussed this, but I guess it never really
> happened. So, something to do :-)
>
> Hannes> What if I have a simple breakpoint like 'break some-file.c:123', is there even any
> Hannes> symbol that can be expanded with expand_symtabs_matching()?
>
> Nope, but then again it isn't called in this scenario; at least not if
> "some-file.c" exists.
I should have clarified that I'm currently investigating why
*pending* breakpoints slow down gdb so much.
The last 3 days I've been staring a lot at profiling flamegraphs
of gdb for the breakpoint types (again, pending only) I use
most ('b some-file.c:123' & 'b function'), and expand_symtabs_matching()
is one of the biggest time-consumers.
Similar, for the case of a simple function name as pending breakpoint,
it's cp_canonicalize_string_no_typedefs() called by find_linespec_symbols(),
that's taking most of the time.
And I'm wondering if this call is necessary if you only use the function name
without arguments (like 'function' or Class::member_function).
If you are interested, I could also send you the profiling flamegraphs.
Regards
Hannes Domani