From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20064 invoked by alias); 20 May 2003 11:10:44 -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 19890 invoked from network); 20 May 2003 11:10:41 -0000 Received: from unknown (HELO nile.gnat.com) (205.232.38.5) by sources.redhat.com with SMTP; 20 May 2003 11:10:41 -0000 Received: by nile.gnat.com (Postfix, from userid 1345) id 8AE9CF2CB5; Tue, 20 May 2003 07:10:41 -0400 (EDT) From: Paul Hilfinger To: carlton@math.stanford.edu Cc: ezannoni@redhat.com, drow@mvista.com, cagney@redhat.com, gdb-patches@sources.redhat.com, jimb@redhat.com, brobecker@gnat.com In-reply-to: (message from David Carlton on 19 May 2003 09:35:27 -0700) Subject: Re: [rfa] teach lookup_symbol about namespace scope References: <20030519095521.38880F2D9E@nile.gnat.com> Message-Id: <20030520111041.8AE9CF2CB5@nile.gnat.com> Date: Tue, 20 May 2003 11:10:00 -0000 X-SW-Source: 2003-05/txt/msg00361.txt.bz2 David, > > 2. We generally expect multiple symbol matches, rather than just taking > > the first match, and therefore our main lookup routine returns a list > > of symbols. > We could probably use this feature in the non-Ada case, too, to get > C++ right... Perhaps a lookup procedure with a function parameter that serves as a callback. The procedure would call its callback argument with each matching symbol (and the usual void* kludge ... uh, I mean ... argument for extra state information); the callback could return 0 or 1 to indicate whether to stop. The current lookup_symbol could simply use this routine. > > 3. Linkage (mangled) names have the form > > __ > > and we need to be able to match this name given either > > either __ or . > > I'm curious: how frequent is this optional suffix? Because this looks > so simple that it seems like the time costs for demangling would be > very small: all you have to do is skip "prefix__" and then check for > the optional suffix (which I assume is easy to recognize?), and it > seems to me that other costs in building symbol information would > swamp that. And we could design a scheme where, if the suffix was > absent, the mangled and demangled names would share memory, since the > demangled name is a final substring of the mangled name. Sorry; I was unclear. The MANGLED names have the form shown, but __ is NOT the demangled name. Binary operators get renamed and "." goes to "__". Hmm. We did the latter mangling because of fear that some linkers or assemblers would not take kindly to "."s in names. Perhaps revisitation is in order; I honestly don't know what the situation is these days vis-a-vis non-alphanumeric characters in symbol names. > Do Ada symbols have both the demangled and linkage name set? Because > if you're never setting the demangled name, I would think that you > wouldn't have to use a special macro in the Ada case. (By the way, we > used to have a different macro called SYMBOL_SEARCH_NAME, but that's a > separate issue.) I'm not sure which of your macros then would yield the right value for all languages. The idea was for SYMBOL_SEARCH_NAME to return the form of name for a symbol that a specific language does searches on. We still need SYMBOL_NATURAL_NAME and SYMBOL_PRINT_NAME to print out demangled forms of the name (which for Ada would involve a procedure call). Paul