Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew Burgess <aburgess@broadcom.com>
To: <gdb@sourceware.org>
Cc: <a.cavallo@cavallinux.eu>
Subject: Re: gdb symbol lookup very slow
Date: Wed, 28 May 2014 22:43:00 -0000	[thread overview]
Message-ID: <5385A4A7.2010909@broadcom.com> (raw)
In-Reply-To: <53859746.7030601@cavallinux.eu>

On 28/05/2014 8:59 AM, Antonio Cavallo wrote:
> I'm having hard time debugging a (very large) C++ library under gdb (gdb
> 7.7.1, gcc 4.8, binutils 2.22).

Details of your target architecture / operating system /etc would be
helpful.

> 
> 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):
> 
>   strcmp_iw
>   find_pc_sect_psymtab
>   symbol_get_demangled_name
>   symbol_search_name
> 
> I suspect gdb doesn't cache the symbols: is there any way to speedup
> this lookup? Is there any other explanation for why gdb is so much
> slower than visual studio?

I suspect you've not mentioned something important :) In "normal"
circumstances, once a breakpoint has been placed, and the program being
debugged has been resumed, then there should be no time spent inside gdb.

Are you by chance using conditional breakpoints?  Or stepping, or using
some other commands?

The best thing would be to post a small example session, an annotate
which commands you feel are taking longer than expected.  Also, you
mention that you profiled gdb, assuming that it's not too large, making
the profile data available might allow some more insight.

Thanks for reporting this issue, and taking the time to investigate it.

Andrew


  reply	other threads:[~2014-05-28  8:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-28  8:56 Antonio Cavallo
2014-05-28 22:43 ` Andrew Burgess [this message]
2014-05-29  2:48   ` Antonio Cavallo
2014-05-29 20:40 ` Jan Kratochvil

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5385A4A7.2010909@broadcom.com \
    --to=aburgess@broadcom.com \
    --cc=a.cavallo@cavallinux.eu \
    --cc=gdb@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox