This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Slow handling of C++ symbol names


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]