This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: very slow gdb stepping.
- From: PaweÅ Sikora <pawel dot sikora at agmk dot net>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb at sourceware dot org
- Date: Sun, 01 Apr 2012 12:44:06 +0200
- Subject: Re: very slow gdb stepping.
- References: <1809128.jWeFzAnxpv@localhost> <20120331215613.GA1439@host2.jankratochvil.net>
On Saturday 31 of March 2012 23:57:18 Jan Kratochvil wrote:
> On Sat, 31 Mar 2012 15:05:09 +0200, PaweÅ Sikora wrote:
> > during debugging a large c++ application an each gdb step (next or step-in)
> > takes from ~2 to ~30 seconds which is horribly slow and uncomfortable :(
> [...]
> > http://carme.pld-linux.org/~pluto/gdb-cpuhog/
>
> The name gdb-7.4.50-0.20120120 it suggests a snapshot with performance
> regression later already fixed on trunk by Tom Tromey. This performance
> regression was not present in 7.4 and it will not be present in 7.5.
>
> I have fixed this regression by a backport in 7.4.50.20120120-35.fc17,
> the 20120120 snapshot date may suggest your GDB is somehow Fedora derived.
> http://pkgs.fedoraproject.org/gitweb/?p=gdb.git;a=commitdiff;h=ea0fcb4584cb04c938e32e44ad21a04c6225c5a1
> ->
> FYI: remove extraneous block from dw2_map_symtabs_matching_filename
> http://sourceware.org/ml/gdb-patches/2012-02/msg00409.html
> FYI: fix some performance bugs with .gdb_index
> http://sourceware.org/ml/gdb-patches/2012-02/msg00413.html
one more observation: during stepping the collect_symtabs_from_filename
is called many [*] times for the same file which looks suboptimal for large
binaries and linear list scanning in start_subfile.
[*]
#0 collect_symtabs_from_filename (file=0x505b4f0 "ProjectManager.cpp") at linespec.c:2123
#1 0x000000000054c924 in symtabs_from_filename (user_filename=0x7fff5fc4f2d0, is_quote_enclosed=<optimized out>, p=<optimized out>, argptr=0x7fff5fc4f5a0) at
linespec.c:2175
#2 decode_line_internal (self=0x7fff5fc4f2b0, argptr=0x7fff5fc4f5a0) at linespec.c:912
#3 0x000000000054e1eb in decode_line_full (argptr=0x7fff5fc4f5a0, flags=<optimized out>, default_symtab=<optimized out>, default_line=<optimized out>, canoni
cal=0x7fff5fc4f3b0, select_mode=0x739a37 "all", filter=0x0) at linespec.c:1223
#4 0x000000000050244a in decode_linespec_default (s=0x7fff5fc4f5a0, sals=0x7fff5fc4f570, b=<optimized out>) at breakpoint.c:12300
#5 0x0000000000508fce in addr_string_to_sals (b=0x1dc7af0, addr_string=<optimized out>, found=0x7fff5fc4f65c) at breakpoint.c:12159
#6 0x000000000050d44b in breakpoint_re_set_default (b=0x1dc7af0) at breakpoint.c:12235
#7 0x00000000004feff7 in breakpoint_re_set_one (bint=0x1dc7af0) at breakpoint.c:12350
#8 0x000000000056b1db in catch_errors (func=0x4fefb0 <breakpoint_re_set_one>, func_args=0x1dc7af0, errstring=0x3e3a5b0 "Error in re-setting breakpoint 1: ",
mask=6) at exceptions.c:546
#9 0x000000000050d5d2 in breakpoint_re_set () at breakpoint.c:12374
(...)