From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13830 invoked by alias); 26 Nov 2003 16:24:45 -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 13822 invoked from network); 26 Nov 2003 16:24:42 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 26 Nov 2003 16:24:42 -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 hAQGOgH06366 for ; Wed, 26 Nov 2003 11:24:42 -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 hAQGOfw03118; Wed, 26 Nov 2003 11:24:41 -0500 Message-ID: <3FC4D3C9.7050303@redhat.com> Date: Wed, 26 Nov 2003 16:24: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/msg00259.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 building a uberbaum tree with a snapshot this morning (2003/11/26). The uberbaum built a gdb, but didn't complete building everything. I tried using this gdb with the new demangler on the monotone executable that take 30 seconds or so to load. gdb segfaults when loading the debugging information. This is definitely caused by reading in the debugging information. gdb was able to read in a stripped version of the same file and the gdb dies in libiberty/cp-demangle.c:d_print_comp which is called from demangler. I have made the monotone files available at http://people.redhat.com/wcohen/gdb_tuning/ --Will