From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32409 invoked by alias); 16 May 2013 19:42:31 -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 32398 invoked by uid 89); 16 May 2013 19:42:30 -0000 X-Spam-SWARE-Status: No, score=-1.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,SPF_SOFTFAIL autolearn=no version=3.3.1 Received: from oproxy6-pub.bluehost.com (HELO oproxy6-pub.bluehost.com) (67.222.54.6) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with SMTP; Thu, 16 May 2013 19:42:29 +0000 Received: (qmail 11675 invoked by uid 0); 16 May 2013 19:42:24 -0000 Received: from unknown (HELO box531.bluehost.com) (74.220.219.131) by cpoproxy3.bluehost.com with SMTP; 16 May 2013 19:42:24 -0000 Received: from [173.9.45.73] (port=51361 helo=[10.1.37.145]) by box531.bluehost.com with esmtpsa (SSLv3:CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1Ud44F-0000wg-Jc for gdb@sourceware.org; Thu, 16 May 2013 13:42:23 -0600 Message-ID: <1368733335.4101.743.camel@pdsdesk> Subject: [GDB 7.6/GCC 4.8.0] Slowdown in GDB macro processing for cores? From: Paul Smith Reply-To: psmith@gnu.org To: gdb@sourceware.org Date: Thu, 16 May 2013 19:42:00 -0000 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/msg00074.txt.bz2 Hi all. Is anyone aware of an issue with a big slowdown running macros on core files? I'm not sure if this is related to GCC 4.8 or GDB 7.6, or what, but I'm seeing a 4x or more slowdown when running macros on core files from previous releases. Running against a live process is the same speed as before. Details: we were building/debugging with the system compiler and debugger (e.g., GCC 4.5.2 / GDB 7.2). Speed of macros when dealing with core files here was acceptable. FYI, our code is C++ with a small to moderate number of templates and compiled (in this case) with "-g", and no optimization. I wanted to use a new compiler with an encapsulated environment so we could unify our build toolchain. I created a separately-installed version of GCC 4.8.0/binutils 2.23.2. Then we discovered that trying to use older GDB instances with the results of this build failed, because they couldn't read the DWARF4 object format generated by GCC 4.8.0. I thought about dropping back to an older DWARF format but instead I built GDB 7.6 and added that to our toolchain. Now we can debug and everything works well, except that we've noticed this major slowdown only when debugging corefiles. The macros are nothing fancy: they just walk through some of our data structures printing interesting information; for example: set $current = $arg0.first set $size = 0 while $current printf "node[%u]: id=", $size if $current->flags & 1 printf "*" end if $current->flags & 2 printf "^" end printf "%d, localId=%d, incarnation=%d, type=%d, state=%d\n", $current->node->nodeId, $current->node->localId, $current->incarnationNumber, $current->node->nodeType, $current->node->nodeState set $current = $current.next set $size++ end Against a core file it takes a second or longer per iteration of this loop! FWIW, the class this macro operates on is very large and contains a lot of data per object. Any ideas? Is there a handy way to tell where the slowdown is happening here? Should we just drop back to DWARF2 or DWARF3 (I haven't checked if that will help tho)?