From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21452 invoked by alias); 22 May 2013 20:52:11 -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 21440 invoked by uid 89); 22 May 2013 20:52:11 -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 oproxy13-pub.unifiedlayer.com (HELO oproxy13-pub.unifiedlayer.com) (69.89.16.30) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with SMTP; Wed, 22 May 2013 20:52:09 +0000 Received: (qmail 8720 invoked by uid 0); 22 May 2013 20:52:08 -0000 Received: from unknown (HELO box531.bluehost.com) (74.220.219.131) by oproxy13.unifiedlayer.com with SMTP; 22 May 2013 20:52:08 -0000 Received: from [146.115.71.23] (port=59889 helo=[172.31.1.206]) by box531.bluehost.com with esmtpsa (SSLv3:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UfG11-0001mH-K3; Wed, 22 May 2013 14:52:07 -0600 Message-ID: <1369255926.7209.173.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 20:52: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/msg00107.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. I'll see what I can do. Meantime, git bisect declares this commit to be the one that introduced the slow behavior: 677b1bfabd372790dca4dad32fcb05dd77658728 is the first bad commit commit 677b1bfabd372790dca4dad32fcb05dd77658728 Author: Keith Seitz Date: Fri Nov 16 20:54:28 2012 +0000 PR c++/13615 * cp-namespace.c (cp_lookup_symbol_in_namespace): Add SEARCH parameter and pass it to lookup_symbol_file. (cp_lookup_symbol_imports): Tell cp_lookup_symbol_in_namespace to search base classes. (cp_lookup_symbol_namespace): Likewise. (lookup_namespace_scope): Likewise. (lookup_symbol_file): Add SEARCH parameter. If SEARCH is non-zero and no symbol is found, lookup the class and call cp_lookup_nested_symbol. (find_symbol_in_baseclass): New function. (cp_lookup_nested_symbol): Do not let cp_lookup_symbol_in_namespace search through base classes. Do that later when there is no global symbol match. PR c++/13615 * gdb.cp/baseenum.cc: New file. * gdb.cp/baseenum.exp: New file. * gdb.cp/derivation.cc (A): Add copyright. Add a typedef. (B): Use A::value_type instead of int. Change all references. (D): Use value_type instead of int. Change all references. (E): Likewise. (F); Likewise. (Z): New class. (ZZ): New class. (N, Base, Derived): New namespace and classes. (main): Add instances of Z and ZZ. Make sure all symbols from N are kept. * gdb.cp/derivation.exp: Update typedef changes in tests. Add tests for class typedefs both before and after starting the inferior. Add tests for searching for a typedef while stopped in a method. :040000 040000 f605271943211b58d6946f8f837053aac8e2b185 0afb509700f9a0d88f26fb498615c9c906bfeb1d M gdb