From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17224 invoked by alias); 29 May 2014 19:22:24 -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 17210 invoked by uid 89); 29 May 2014 19:22:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 29 May 2014 19:22:22 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s4TJMGwK012284 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 29 May 2014 15:22:16 -0400 Received: from host2.jankratochvil.net (ovpn-116-37.ams2.redhat.com [10.36.116.37]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s4TJMCRo015627 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Thu, 29 May 2014 15:22:15 -0400 Date: Thu, 29 May 2014 20:40:00 -0000 From: Jan Kratochvil To: Antonio Cavallo Cc: gdb@sourceware.org Subject: Re: gdb symbol lookup very slow Message-ID: <20140529192212.GA12686@host2.jankratochvil.net> References: <53859746.7030601@cavallinux.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53859746.7030601@cavallinux.eu> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-05/txt/msg00084.txt.bz2 On Wed, 28 May 2014 09:59:02 +0200, Antonio Cavallo wrote: > Hi, > I'm having hard time debugging a (very large) C++ library under gdb (gdb > 7.7.1, gcc 4.8, binutils 2.22). > > The main issue is the time it takes to reach a breakpoint: gdb takes an > insane amount of time (order of 2mins) vs vs2012 (a couple of seconds). > > I've profiled gdb and the top functions called during the debugging are > (more than 90% is spent in these): Try to use gdb-add-index (gdb/contrib/gdb-add-index.sh or /usr/bin/gdb-add-index on some systems) with gdb-7.7+. That the index is present in a binary you can verify with: $ readelf -WS /usr/lib/debug/bin/bash.debug|grep -w gdb_index [34] .gdb_index PROGBITS 0000000000000000 21bc44 0252fa 00 0 0 1 Or with recent enough readelf even with: readelf --debug-dump=gdb_index /usr/lib/debug/bin/bash.debug or with elfutils: eu-readelf --debug-dump=gdb_index /usr/lib/debug/bin/bash.debug You should check you use .gdb_index version 8, older versions had various issues and they can get ignored by recent GDBs. There is also an unrelated GDB performance Bug which happens with binaries optimized by 'dwz' but I do not think that is your described case. Bug 16405 - backtrace takes GBs and minutes with dwz -m https://sourceware.org/bugzilla/show_bug.cgi?id=16405 Jan