From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15235 invoked by alias); 8 Jan 2003 01:04: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 15209 invoked from network); 8 Jan 2003 01:04:07 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 8 Jan 2003 01:04:07 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18W6VX-00073R-00; Tue, 07 Jan 2003 21:03:55 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18W4d6-0007wv-00; Tue, 07 Jan 2003 20:03:36 -0500 Date: Wed, 08 Jan 2003 01:04:00 -0000 From: Daniel Jacobowitz To: Paul Hilfinger Cc: Elena Zannoni , Adam Fedor , GDB Patches Subject: Re: Demangling and searches Message-ID: <20030108010336.GB30387@nevyn.them.org> Mail-Followup-To: Paul Hilfinger , Elena Zannoni , Adam Fedor , GDB Patches References: <200301072354.PAA18230@tully.CS.Berkeley.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200301072354.PAA18230@tully.CS.Berkeley.EDU> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00071.txt.bz2 On Tue, Jan 07, 2003 at 03:54:36PM -0800, Paul Hilfinger wrote: > > For some time, I've been meaning to ask a basic question about GDB > search strategy: for language implementations that mangle their > identifiers, the standard procedure in GDB at the moment is to search > for the demangled identifier among the demangled identifiers of the > symbol table, and to speed this search up by precomputing and storing > the demangled symbol names. Why? > > We used to do that for Ada mode in GDB, but subsequently changed our > approach entirely. For Ada, we MANGLE the symbol we're searching for > and then search among the MANGLED (i.e., raw, unmodified, warm-from- > the-executable) names. We do very little demangling as a result, and > do not devote any storage to demangled names. Of course, we do have > to demangle during the 'info XXX' symbol searches, but that is not a > common operation (at least for our customers), and therefore we saw > little to be gained by storing the demangled names. > > Is there some unfortunate feature of C++ and ObjC mangling that > completely prevents our approach for those languages? What was the Bingo. If you want to get a whiff of what the demangling looks like, check libiberty/cp-demangle.c; that's just for the GNU v3 mangling scheme. cplus-dem.c supports some others. It's hideously complicated and includes type information, as part of the language support for overloading. If it were just namespace/enclosing class information this would be practical, but for C++ that's too much. Ada's "mangling" appears to be much more simplistic. > rationale behind the current strategy? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer