From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2706 invoked by alias); 26 Nov 2003 20:45:08 -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 2665 invoked from network); 26 Nov 2003 20:45:07 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 26 Nov 2003 20:45:07 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id hAQKj7H18513 for ; Wed, 26 Nov 2003 15:45:07 -0500 Received: from redhat.com (wcohen.devel.redhat.com [172.16.56.117]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id hAQKj6w23949; Wed, 26 Nov 2003 15:45:06 -0500 Message-ID: <3FC510D2.8070008@redhat.com> Date: Wed, 26 Nov 2003 20:45:00 -0000 From: Will Cohen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030922 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Cagney CC: Daniel Jacobowitz , gdb@sources.redhat.com Subject: Re: Slow handling of C++ symbol names References: <3FBBDC27.50204@redhat.com> <20031119211355.GA31069@nevyn.them.org> <3FBCE71B.7060100@redhat.com> <20031120161915.GA1282@nevyn.them.org> <3FBCF1C9.5040106@redhat.com> <20031121175832.GA30361@nevyn.them.org> <3FC4B844.1080302@redhat.com> In-Reply-To: <3FC4B844.1080302@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-11/txt/msg00260.txt.bz2 Andrew Cagney wrote: >> But without looking at the data we've no idea how substantial any >> >>> particular part really is. For instance, when analysing the bcache >>> found that when debugging a C program every entry is 28 bytes in size! >>> >>> 'foo(int)' can be broken down into "foo" "(int)" the latter only >>> being demanged and stored on-demand. >> >> >> >> "They" tell me that the demangler did not support doing this. But it >> may soon. >> >> Will, you may want to test a CVS snapshot from today or later. The >> demangler for GNU v3 was replaced last night; the new one appears to be >> about twice as efficient. > > > FYI, Will got hold of an RPM based on 20031117 and I believe the > performance numbers came back the same as 6.0 :-( That would make it > post your changes but pre the new demangler. > > I guess we get to restart the analysis :-( > > Andrew I tried a very recent snapshot of gdb and libiberty (used the uberbaum checkout the to get pieces 2003/11/25). The uberbaum appears to be broken and doesn't build to completion, but it does build gdb executable. However, the new cp-demangler.c gets a segfault error when the gdb executable is loading the monotone executable. I have filed a bugzilla entry, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13206 . It looks like there is some more work required. The problem is definitely related to the processing of the debugging information. The gdb executable loads the stripped version of the monoexecutable without problem. -Will