From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20108 invoked by alias); 20 Nov 2003 16:58:01 -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 20099 invoked from network); 20 Nov 2003 16:58:01 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 20 Nov 2003 16:58:01 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1AMs80-0007Kj-Lt; Thu, 20 Nov 2003 11:58:00 -0500 Date: Thu, 20 Nov 2003 16:58:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Will Cohen , gdb@sources.redhat.com Subject: Re: Slow handling of C++ symbol names Message-ID: <20031120165800.GA25667@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Will Cohen , gdb@sources.redhat.com References: <3FBBDC27.50204@redhat.com> <20031119211355.GA31069@nevyn.them.org> <3FBCE71B.7060100@redhat.com> <20031120161915.GA1282@nevyn.them.org> <3FBCF1C9.5040106@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FBCF1C9.5040106@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-11/txt/msg00172.txt.bz2 On Thu, Nov 20, 2003 at 11:54:33AM -0500, Andrew Cagney wrote: > > > >Well, I remember fixing some startup time issues since then :P For > >instance, the cache shared between minimal and partial symbols should > >cut demangling time about in half. > > Ah, this: symbol_set_names? I was looking at the demangler. > > >Which leads to the question. Why does GDB demangle symbols? My > >>simplistic understanding of the code is that GDB only needs the "iw" > >>(a.k.a., demangled string up to but excluding the lparen and ignoring > >>white space) part of the symbol in the search table (the rest isn't so > >>critical and can be constructed on-demand). > > > > > >A substantial amount of demangling is needed to produce the part of > >the symbol before the lparen; consider templates. Also, we need the > >full names in the minimal symbol for break 'foo(int)' with quotes to > >work. And there are assumptions of unique symbol names in our > >hashing/searching, IIRC. > > 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. But does doing that save any measurable time in the demangling? I'm guessing very little, because of the way v3 mangled substitutions work. Someone more familiar with the demangler could have a look at this. Also, the demangler is currently being rewritten (again). Result might be faster; DJ posted it to gcc-patches a few days ago. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer