names of symbols

names of symbols

[David Carlton]

I've been thinking about what methods symbols should provide for
interacting with their names.  This is longish-term stuff, initially
prompted by Paul's description of what Ada does: I was trying to
figure out if I didn't like it because it was really a bad idea, or
just because of "not invented here" reasons.

I'm coming to the conclusion that C++ will eventually want to be more
flexible in this regard as well.  Right now, we rely on demangled
names too much; those names contain quite a lot of information, and we
should, whenever possible, be getting (and presumably also storing)
that information in a different way.  This might fit into Andrew's
"symbol auxiliary" ideas, too.

Of course, we'll never be able to entirely get away from trying to
parse names: they come as user input, after all.  But this matching is
asymmetric: if a lookup function wants to see if a user-input string
matches a symbol's natural name, then instead of having the lookup
function ask for the symbol's natural name and then do some sort of
comparison function between that name and what the user typed, it
might be better to embed the comparison function within the symbol
itself, so that no natural name has to be computed by the symbol if
there's a better way to do things.  This puts the comparison function
closer to the data that it's dealing with, and gives different
languages more flexibility to implement whatever behavior is useful
for them.

In fact, we already basically do this: we have a macro
SYMBOL_MATCHES_NATURAL_NAME for this purpose.  (Note that strcmp_iw is
already asymmetric, so having a macro like this around is useful to
make sure that you get your arguments in the right order.)  So we
could just, in the future, promote this to a full-fledged function
(albeit with a macro front end, just like SYMBOL_NATURAL_NAME).

Paul: would doing this instead of adding SYMBOL_SEARCH_NAME fit Ada's
needs?  I guess that we'd probably also want to add a SYMBOL_HASH
method as well; are there any other bits that I'm missing?  Of course,
the more data we generate on-demand, the more memory-management
headaches we start running into, but that's a separate story...

David Carlton
carlton@kealia.com

Re: names of symbols

[Paul N. Hilfinger]

David,

This certainly sounds like a convenient direction from our standpoint.  A 
few considerations come to mind:

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.  I'm not sure that 
      SYMBOL_MATCHES_NATURAL_NAME (symbol, name);
   conveys that NAME might not be a natural name.  

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.

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?

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)?

Paul

Re: names of symbols

[David Carlton]

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

Re: names of symbols

[Paul N. Hilfinger]

David,

> > 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.

Another possibility is simply to have SYMBOL_MATCHES_NATURAL_NAME be sensitive
to the current language as well as the symbol's language.  

> > 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)?
> 
> 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.

Well, not necessarily.  I had in mind a callback signature like this:

      int (*callback) (struct symbol* sym, void* data);

The callback's return value indicates whether to continue the search or halt.

However, iterators work for me, too.  The callback scheme is usually easier 
on the fellow implementing the collection type, whereas the iterator scheme
is easier on the fellow using the collection type.  And since you would 
presumably be the former and I the latter....

	      - * -

I thought of one other little piece that might be useful:

  SYMBOL_COMPARE_NATURAL_NAME (symbol0, symbol1)

to be used for anything that needs to sort an array of symbols by natural
name.  Reason: this facilitates a design in which we never have to 
materialize a demangled name except transiently (for printing).  

Paul

Re: names of symbols

[David Carlton]

On Wed, 2 Jul 2003 22:39:23 -0700, "Paul N. Hilfinger" <hilfingr@otisco.mckusick.com> said:

> I thought of one other little piece that might be useful:

>   SYMBOL_COMPARE_NATURAL_NAME (symbol0, symbol1)

> to be used for anything that needs to sort an array of symbols by natural
> name.  Reason: this facilitates a design in which we never have to 
> materialize a demangled name except transiently (for printing).  

Good idea.

David Carlton
carlton@kealia.com