Re: RFA: Search for symbol names the same way they're hashed.

[Jim Blandy <jimb at redhat dot com>]

David Carlton <carlton@math.stanford.edu> writes:
> 1) This concept of 'a name that is as demangled as possible' is a
> pretty important one and occurs in multiple places in GDB's sources,
> so let's formalize it:
> 
> /* Macro that returns the demangled name of the symbol if if possible
>    and the symbol name if not possible.  This is like
>    SYMBOL_SOURCE_NAME except that it doesn't depend on the value of
>    'demangle' (and is hence more suitable for internal usage).  The
>    result should never be NULL.  */
> 
> /* FIXME: carlton/2002-09-26: Probably the situation with this and
>    SYMBOL_SOURCE_NAME should be rethought.  */
> 
> #define SYMBOL_BEST_NAME(symbol)					\
>   (SYMBOL_DEMANGLED_NAME (symbol) != NULL				\
>    ? SYMBOL_DEMANGLED_NAME (symbol)					\
>    : SYMBOL_NAME (symbol))
> 
> (I'm not exactly wedded to the name 'SYMBOL_BEST_NAME'; it was the
> first acceptable name that I thought of, given that SYMBOL_SOURCE_NAME
> was already taken to mean something subtly different.)

Yeah, I think we need something like that, too.

How about SYMBOL_DEMANGLEDEST_NAME?  Um.

I just did a quick survey of the uses of SYMBOL_SOURCE_NAME.  They all
fall into two categories:
- printing symbol names, and
- sort comparison functions.

The first usage is exactly correct: the way a symbol prints should
respect the current demangling setting.

The second usage seems wrong to me: if you sort under one demangling
setting, but then search under a different one, well, ... duh.

The source code name of a symbol does not depend depend on the current
demangling setting; the way it should be printed obviously does.  So
I'd suggest:
- changing the first category of uses to use SYMBOL_PRINT_NAME,
  a new macro which will be defined just like the current
  SYMBOL_SOURCE_NAME (or David's defn below looks nice, too), and
- defining a new SYMBOL_SOURCE_NAME which does what David's
  SYMBOL_BEST_NAME does above.

This could be two separate patches --- one for each of the steps above
--- but I think it should actually be one patch, since you either want
to accept or revert the two as a unit; having either one without the
other is just a mess.