From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3498 invoked by alias); 2 Jul 2003 16:06:38 -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 3487 invoked from network); 2 Jul 2003 16:06:37 -0000 Received: from unknown (HELO hawaii.kealia.com) (216.101.126.244) by sources.redhat.com with SMTP; 2 Jul 2003 16:06:37 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id EEB85BF06; Wed, 2 Jul 2003 09:06:36 -0700 (PDT) To: Hilfinger@otisco.mckusick.com Cc: gdb@sources.redhat.com, hilfinger@gnat.com Subject: Re: names of symbols References: <200307020945.h629jlp17671@otisco.McKusick.COM> From: David Carlton Date: Wed, 02 Jul 2003 16:06:00 -0000 In-Reply-To: <200307020945.h629jlp17671@otisco.McKusick.COM> (Paul N. Hilfinger's message of "Wed, 2 Jul 2003 02:45:47 -0700") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Rational FORTRAN, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-07/txt/msg00035.txt.bz2 On Wed, 2 Jul 2003 02:45:47 -0700, "Paul N. Hilfinger" said: > 1. Most trivial (and therefore most annoying and contentious (;->)): the > name SYMBOL_MATCHES_NATURAL_NAME is not entirely descriptive of what > we do and of what one would want to do. As I described our strategy > to you, we first mangle the name and then search for a match with > SYMBOL_SEARCH_NAME. Right. So I'm suggesting that SYMBOL_MATCHES_NATURAL_NAME would, in the Ada case, do exactly that. And, in an ideal world, I'd like SYMBOL_NATURAL_NAME, when given an Ada symbol, to demangle the name (but the point of SYMBOL_MATCHES_NATURAL_NAME is that it wouldn't actually have to call SYMBOL_NATURAL_NAME, and hence demangle the name, in the Ada case.) > 2. This makes me wonder a little about cross-language > queries---e.g., asking for an Ada symbol from C++ code. How does > C++ know to mangle? Well, probably the solution of using 'set > lang ada' temporarily in this case isn't so terribly bad. Yeah, that's a good question. We might be able to get this to work without that being necessary - the language is stored in the symbol, after all - but I could imagine problems arise. > 3. I was a bit puzzled about what to do with this, from > build_minimal_symbol_hash_tables: > if (SYMBOL_DEMANGLED_NAME (msym) != NULL) > add_minsym_to_demangled_hash_table (msym, > objfile-> msymbol_demangled_hash); > In Ada, I have no need of this hash table, but we DO need to demangle > names. It seems odd, but am I expected to provide a SYMBOL_DEMANGLED_NAME > that is NULL and a SYMBOL_NATURAL_NAME that is ... um ... natural? Um. Good question. Hmm. Another problem that I thought of: the partial symbol table doesn't use a hash table at all, but rather an ordered list: so we'd either have to convert that to hash tables (probably a good idea) or figure out a way to handle that special case as well, if we go with my plan. > 4. As to other bits: what did you think of my suggestion of handling > multiple matches with a version of symbol_lookup that takes a > call-back as argument (i.e., to be called with each matching > symbol)? Oh, I'd completely forgotten about that, whoops. Hmm. My instinct is to use iterators for stuff like that (see dictionary.h for an example). On the one hand, I feel a little guilty about that, because that's more a C++-style idea instead of a C-style idea. But they're a little more flexible than callbacks: they work just as well as callbacks if you're trying to take an action on every symbol, and they work better if you're looking for a specific symbol and want to stop once you've found it. David Carlton carlton@kealia.com