From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5238 invoked by alias); 2 Dec 2003 22:09:22 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 5218 invoked from network); 2 Dec 2003 22:09:22 -0000 Received: from unknown (HELO mclean.mail.mindspring.net) (207.69.200.57) by sources.redhat.com with SMTP; 2 Dec 2003 22:09:22 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1ARIhQ-0007IN-00; Tue, 02 Dec 2003 17:08:52 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 683774B362; Tue, 2 Dec 2003 17:09:07 -0500 (EST) To: ac131313@redhat.com, wcohen@redhat.com Subject: Re: Slow handling of C++ symbol names Cc: drow@mvista.com, gdb@sources.redhat.com Message-Id: <20031202220907.683774B362@berman.michael-chastain.com> Date: Tue, 02 Dec 2003 22:09:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2003-12/txt/msg00031.txt.bz2 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