From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7848 invoked by alias); 5 Mar 2004 03:59:56 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 7824 invoked from network); 5 Mar 2004 03:59:56 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 5 Mar 2004 03:59:56 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Az6V9-0003YQ-Ha; Thu, 04 Mar 2004 22:59:55 -0500 Date: Fri, 05 Mar 2004 03:59:00 -0000 From: Daniel Jacobowitz To: Paul Hilfinger Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA] Introduce notion of "search name" Message-ID: <20040305035955.GH5320@nevyn.them.org> Mail-Followup-To: Paul Hilfinger , gdb-patches@sources.redhat.com References: <20040303191550.7307DF2DB8@nile.gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040303191550.7307DF2DB8@nile.gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03.o/txt/msg00087.txt Message-ID: <20040305035900.eTtGKiSlqi3Pd7ZW85uQQdeUZhgfaeZnXZRH5hBGSpY@z> On Wed, Mar 03, 2004 at 02:15:50PM -0500, Paul Hilfinger wrote: > > The following patch does nothing except to prepare the way for some later > Ada modifications by providing a few "hooks". I've discussed this > modification earlier on this newsgroup. At the moment, I've given > the definitions placeholder definitions that simply result in the > current semantics. I propose to change them when Ada support is turned on. > > The idea is to define "search name" as "the name that a language > module uses when searching for this symbol". As discussed earlier, > the search name would be normally be the natural name, but in the case > of Ada, would just be the linkage name. > > The modification to the signature of symbol_natural_name is to allow the > option of delayed (lazy) evaluation of the demangled name, which is > actually the point of introducing search names. I'm no symtab maintainer, but I've had my hands in this code lately, so I have a couple of comments anyway. There are some of things I don't like about this patch, unfortunately. It doesn't address on of the thornier problems I hit when doing the same thing, namely that of allocation. OK, someone uses SYMBOL_DEMANGLED_NAME, we lazily allocate a demangled name - where? The objfile is not available. I think there may be no option but to pass the objfile to SYMBOL_DEMANGLED_NAME. What did you do for Ada? You define SYMBOL_DEMANGLED_SEARCH_NAME. What's it really good for, and how does it do any good? You only use it for the minimal symbol hash tables; the fundamental problem with minimal symbols is that we don't know their language, so I don't know how you can reliably make a language-specific decision like this one. SYMBOL_DEMANGLED_SEARCH_NAME also codifies more than necessary of the difference between the other SYMBOL_*_NAME macros and SYMBOL_SEARCH_NAME. Something that I think may be useful is to use just the basename for the search name and then have language-specific code to cherry-pick the resulting matches afterwards; one big advantage of this is that it lets me sidestep the Java vs. C++ demangling issues. I suspect it is possible (for all supported languages) to unambiguously and efficiently identify the basename. I need to look at some of the other in-use manglings to follow up on that idea though, particularly g++ v2 and ObjC. This idea may only be workable for minimal symbols, because of the namespace inference hacks we use for C++. Oh, and two spaces after a full stop in comments. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer