This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: question about expand_symtabs_matching()


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]