From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28183 invoked by alias); 28 May 2013 17:33:01 -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 28167 invoked by uid 89); 28 May 2013 17:32:59 -0000 X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,RCVD_IN_NIX_SPAM,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; Tue, 28 May 2013 17:32:57 +0000 Received: (qmail 1885 invoked by uid 0); 28 May 2013 17:32:55 -0000 Received: from unknown (HELO box531.bluehost.com) (74.220.219.131) by oproxy9.bluehost.com with SMTP; 28 May 2013 17:32:55 -0000 Received: from [173.9.45.73] (port=54831 helo=[10.1.37.145]) by box531.bluehost.com with esmtpsa (SSLv3:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1UhNlX-000394-2I; Tue, 28 May 2013 11:32:55 -0600 Message-ID: <1369762373.3295.20.camel@pdsdesk> 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: Doug Evans Cc: Tom Tromey , Pedro Alves , gdb Date: Tue, 28 May 2013 17:33:00 -0000 In-Reply-To: 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> <1369264444.7209.184.camel@homebase> <1369284101.7209.197.camel@homebase> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Identified-User: {678:box531.bluehost.com:madscie1:mad-scientist.us} {sentby:smtp auth 173.9.45.73 authed with paul+mad-scientist.us} X-SW-Source: 2013-05/txt/msg00123.txt.bz2 On Tue, 2013-05-28 at 10:10 -0700, Doug Evans wrote: > And I can't offhand explain why you *only* see the slowdown with a > core file and not with a live executable. Well, just because we haven't found a way to make it happen with live debugging doesn't mean it couldn't :-). Since it only seems to happen with cores generated in a specific way (that is, not all core dumps show the issue), I assume that whatever thing is happening in this core file is not happening with live debugging, or at least we haven't found a way to trigger it. > I wasn't aware of the problems with the 12/11/16 patch you found. > I've submitted a minor improvement - IMO the real fix will involve a > lot more effort - gdb's symbol handling is obtuse enough that it's > easy to introduce performance regressions or even overlook basic > performance problems. I'll try the latest Git to see if it makes a difference. > Is it possible to send me the binary+core+scripts+session-log? > [Assuming it's legally possible, there are a few services I know of > for sending large files.] I think it should be OK: sending the core and binary, plus the macro, is enough to show the problem. I'll check and let you know.