Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
To: ac131313@redhat.com, wcohen@redhat.com
Cc: drow@mvista.com, gdb@sources.redhat.com
Subject: Re: Slow handling of C++ symbol names
Date: Tue, 02 Dec 2003 22:09:00 -0000	[thread overview]
Message-ID: <20031202220907.683774B362@berman.michael-chastain.com> (raw)

Andrew Cagney writes:
> I guess we get to restart the analysis :-(

Sounds like a job for GDB QA Guy!  :)

I downloaded Will's executables from:

  http://people.redhat.com/wcohen/gdb_tuning/monostrip
  http://people.redhat.com/wcohen/gdb_tuning/monotone

Here are some memory usage and time numbers.

  gdb   memory  utime  stime  elapsed
  5.3   263M    84.79  26.52  185.92
  6.0   263M    83.17  26.45  181.04
 HEAD    43M     2.78   0.27    3.23

gdb HEAD is from '2003-11-30 06:08:24 UTC'.

My system is a dell inspiron 2500 with intel celeron 800 MHz, 128
megabytes of memory, running without the X window system.  I used "top"
to monitor the memory usage.  I am just reporting the biggest "SIZE"
that I saw in "top" before gdb exited.

So there was no increase in resource usage from gdb 5.3 to gdb 6.0.

All three versions of gdb print "(no debugging symbols found)...".
All three versions can do "break main; run; cont; backtrace"
and print a good looking backtrace.  ("cont" hits a segfault).

I checked "maint print msymbols" with gdb 6.0 and gdb HEAD.
Both versions had a highest msymbol number of 23521.
However, gdb 6.0 produced an output file 266966644 bytes long,
and gdb HEAD produced an output file only 32695256 bytes long.

So next I counted the length of each line in the output.  The length of
the line is a few characters longer than the actual demangled minsym
because of the line index and stuff.

The top ten line lengths for gdb 6.0 were:

  1911946
  1740037
  1699747
  1697323
  1636399
  1626161
  1601007
  1512726
  1512726
  1512641

And the top ten line lengths for gdb HEAD were:

  77302
  77302
  77172
  77172
  77172
  77154
  77147
  77147
  77147
  77147

So, the new demangler is printing different, much smaller output.

In every case that I've seen, the new demangler has been correct,
and the old demangler has had many bugs.  So I have no reason to doubt
the new demangler now.  It would be useful to take some of these
2000-byte mangled symbols and check that the 70K demangled forms are
correct, but I don't have the resources for that yet.

I don't know why gdb HEAD is printing "(no debugging symbols found)...",
even for "monotone".  That's probably the most important bug now.

Michael C


             reply	other threads:[~2003-12-02 22:09 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-02 22:09 Michael Elizabeth Chastain [this message]
2003-12-02 22:23 ` Ian Lance Taylor
2003-12-02 22:29   ` Daniel Jacobowitz
2003-12-03 18:52 ` Andrew Cagney
  -- strict thread matches above, loose matches on Subject: below --
2003-12-03 22:30 Michael Elizabeth Chastain
2003-12-03 20:27 Michael Elizabeth Chastain
2003-12-03 20:35 ` Ian Lance Taylor
2003-12-03 20:17 Michael Elizabeth Chastain
2003-12-03 20:14 Michael Elizabeth Chastain
2003-12-03 19:57 Michael Elizabeth Chastain
2003-12-03 20:16 ` Daniel Jacobowitz
2003-12-03 16:48 Michael Elizabeth Chastain
2003-12-03 16:52 ` David Carlton
2003-12-03 16:58 ` Ian Lance Taylor
2003-12-03 17:08   ` Daniel Jacobowitz
2003-12-03 17:34     ` Ian Lance Taylor
2003-12-03 17:38       ` Daniel Jacobowitz
2003-12-03 17:54         ` Ian Lance Taylor
2003-12-02 22:38 Michael Elizabeth Chastain
     [not found] <3FBBDC27.50204@redhat.com>
2003-11-19 21:13 ` Daniel Jacobowitz
2003-11-20 16:09   ` Andrew Cagney
2003-11-20 16:19     ` Daniel Jacobowitz
2003-11-20 16:54       ` Andrew Cagney
2003-11-20 16:58         ` Daniel Jacobowitz
2003-11-21 17:58         ` Daniel Jacobowitz
2003-11-26 14:27           ` Andrew Cagney
2003-11-26 16:24             ` Will Cohen
2003-11-26 20:48               ` Andrew Cagney
2003-11-26 20:45             ` Will Cohen

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=20031202220907.683774B362@berman.michael-chastain.com \
    --to=mec.gnu@mindspring.com \
    --cc=ac131313@redhat.com \
    --cc=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    --cc=wcohen@redhat.com \
    /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