From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1832 invoked by alias); 22 May 2013 21:02:28 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 1762 invoked by uid 89); 22 May 2013 21:02:22 -0000 X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,SPF_SOFTFAIL autolearn=no version=3.3.1 Received: from oproxy9.bluehost.com (HELO oproxy9.bluehost.com) (69.89.24.6) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with SMTP; Wed, 22 May 2013 21:02:21 +0000 Received: (qmail 12993 invoked by uid 0); 22 May 2013 21:02:08 -0000 Received: from unknown (HELO box531.bluehost.com) (74.220.219.131) by oproxy9.bluehost.com with SMTP; 22 May 2013 21:02:08 -0000 Received: from [146.115.71.23] (port=59998 helo=[172.31.1.206]) by box531.bluehost.com with esmtpsa (SSLv3:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UfGAi-0007Mn-2g; Wed, 22 May 2013 15:02:08 -0600 Message-ID: <1369256527.7209.174.camel@homebase> Subject: Re: [GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores? From: Paul Smith Reply-To: psmith@gnu.org To: Tom Tromey Cc: Pedro Alves , gdb@sourceware.org Date: Wed, 22 May 2013 21:02:00 -0000 In-Reply-To: <87wqqqg4e2.fsf@fleche.redhat.com> References: <1368733335.4101.743.camel@pdsdesk> <51960329.2010802@redhat.com> <1369248335.7209.151.camel@homebase> <1369250399.7209.164.camel@homebase> <87wqqqg4e2.fsf@fleche.redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-Identified-User: {678:box531.bluehost.com:madscie1:mad-scientist.us} {sentby:smtp auth 146.115.71.23 authed with paul@mad-scientist.us} X-SW-Source: 2013-05/txt/msg00108.txt.bz2 On Wed, 2013-05-22 at 14:12 -0600, Tom Tromey wrote: > >>>>> "Paul" == Paul Smith 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