From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 516 invoked by alias); 8 Jan 2003 01:39:31 -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 505 invoked from network); 8 Jan 2003 01:39:31 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by 209.249.29.67 with SMTP; 8 Jan 2003 01:39:31 -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 h081BdB30219 for ; Tue, 7 Jan 2003 20:11:39 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h081dJa24421 for ; Tue, 7 Jan 2003 20:39:19 -0500 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h081dIn16957; Tue, 7 Jan 2003 20:39:18 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id 2D059FF79; Tue, 7 Jan 2003 20:43:40 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15899.33356.615182.202795@localhost.redhat.com> Date: Wed, 08 Jan 2003 01:39:00 -0000 To: Paul Hilfinger Cc: Elena Zannoni , Adam Fedor , GDB Patches , Daniel Jacobowitz Subject: Re: Demangling and searches In-Reply-To: <200301072354.PAA18230@tully.CS.Berkeley.EDU> References: <200301072354.PAA18230@tully.CS.Berkeley.EDU> X-SW-Source: 2003-01/txt/msg00072.txt.bz2 Paul Hilfinger writes: > > 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? > Gdb did that orginally for c++. In October 2000 the behavior was changed to do the search among the demangled names instead of the mangled ones. This way it was able to do a binary search instead of a linear one, given that the names are sorted on the demangled value. I think that what prompted the change was this analysis: http://sources.redhat.com/ml/gdb-patches/2000-06/msg00024.html Unfortunately there is still some lack of clarity around the partial symbol handling. As David Carlton mentions. Partial symbols don't store the demangled names. Elena > 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 > rationale behind the current strategy? > > Thanks for the information. > > Paul Hilfinger