This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores?
- From: Paul Smith <psmith at gnu dot org>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Pedro Alves <palves at redhat dot com>, gdb at sourceware dot org
- Date: Wed, 22 May 2013 17:02:07 -0400
- Subject: Re: [GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores?
- References: <1368733335 dot 4101 dot 743 dot camel at pdsdesk> <51960329 dot 2010802 at redhat dot com> <1369248335 dot 7209 dot 151 dot camel at homebase> <1369250399 dot 7209 dot 164 dot camel at homebase> <87wqqqg4e2 dot fsf at fleche dot redhat dot com>
- Reply-to: psmith at gnu dot org
On Wed, 2013-05-22 at 14:12 -0600, Tom Tromey wrote:
> >>>>> "Paul" == Paul Smith <psmith@gnu.org> writes:
>
> Paul> The interesting thing is both versions are constantly seeking and
> Paul> reading to exactly the same location, over and over again. However GDB
> Paul> 4.6 does it many times more than GDB 7.5.1. For example, I get this
> Paul> combo:
>
> Paul> 14:51:34.423582 lseek(7, 26763264, SEEK_SET) = 26763264 <0.000004>
> Paul> 14:51:34.423609 read(7,
> Paul> "P\361\236\0\0\0\0\0`\361\236\0\0\0\0\0p\361\236\0\0\0\0\0\200\361\236\0\0\0\0\0"...,
> Paul> 4096) = 4096 <0.000015>
>
> A backtrace from one of these seeks or reads might be useful.
>
> Or, gprof.
FYI this seems pretty real so I filed a bug:
http://sourceware.org/bugzilla/show_bug.cgi?id=15519