From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23854 invoked by alias); 20 May 2003 16:17:32 -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 23283 invoked from network); 20 May 2003 16:17:19 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 20 May 2003 16:17:19 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h4KGHAM29737; Tue, 20 May 2003 09:17:10 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Paul Hilfinger Cc: ezannoni@redhat.com, drow@mvista.com, cagney@redhat.com, gdb-patches@sources.redhat.com, jimb@redhat.com, brobecker@gnat.com Subject: Re: [rfa] teach lookup_symbol about namespace scope References: <20030519095521.38880F2D9E@nile.gnat.com> <20030520111041.8AE9CF2CB5@nile.gnat.com> From: David Carlton Date: Tue, 20 May 2003 16:17:00 -0000 In-Reply-To: <20030520111041.8AE9CF2CB5@nile.gnat.com> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg00363.txt.bz2 On Tue, 20 May 2003 07:10:41 -0400 (EDT), Paul Hilfinger said: >> > 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 "__". I guess I'd been assuming/hoping that was normally the demangled name. Binary operators don't worry me so much, but is "." some sort of package/module/etc. operator that shows up all over the place? If so, I guess there's no way around making a copy. >> 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). Ah, interesting. That does sound like a consistent and reasonable way to do things, given your desire to not store demangled names. Thanks for the info! David Carlton carlton@math.stanford.edu