Re: names of symbols

[David Carlton <carlton at kealia dot com>]

On Wed, 2 Jul 2003 02:45:47 -0700, "Paul N. Hilfinger" <hilfingr@otisco.mckusick.com> 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