Re: [RFC] Proposed changes in symbol-handling for Ada

[David Carlton <carlton at kealia dot com>]

On Tue, 20 Jan 2004 05:16:13 -0500 (EST), Paul Hilfinger <hilfingr@gnat.com> said:

> Basically, we found it sufficient to introduce some additional macros in 
> symtab.h: 

> +#define SYMBOL_SEARCH_NAME(symbol)					 \
> +#define SYMBOL_MATCHES_SEARCH_NAME(symbol, name)			\
> +#define SYMBOL_DEMANGLED_SEARCH_NAME(symbol)				 \

These don't seem unreasonable to me, given your desires.  If I were a
symtab maintainer, I would ask for measurements to see how much
time/memory doing things your way saves you, but I'm willing to
imagine that it really does help you.  Given that, my main worry is:

> +  else if (gsymbol->language == language_ada)
> +    {
> +      return ada_demangle (gsymbol->name);
> +    }

It used to be the case that the return value of
SYMBOL_{NATURAL,DEMANGLED,PRINT}_NAME had a lifetime that always
lasted as long as the symbol in question; your proposal would mean
that that would no longer be true.  And changing that assumption makes
me nervous.

I'm not sure what to do about that.  Choices that come to mind are:

1) Have the SYMBOL_DEMANGLED_NAME of Ada symbols always be NULL, and
   the SYMBOL_NATURAL_NAME be the mangled name.  In which case, there's
   no need for the search name stuff, but it makes it harder for Ada
   code to use, say, output code in other portions of GDB.

2) Not allow callers to assume that the output of SYMBOL_NATURAL_NAME
   and friends lasts for very long.  Which is a fragile assumption to
   make, and violations of it will be hard to find.

3) Have Ada symbols save the demangled names of symbols after being
   forced to demangle them.  This could cause a memory increase if you
   for some reason have to demangle lots of names.

I think I would vote for option 3 - after all, one point of your
proposal is that you _don't_ have to demangle lots of names.  And, if
you did have to do that once for some reason, then probably there's a
good chance that you'd have to do it a second time, at which point
caching becomes a time win, if not a space win.

(Hmm: where would you allocate the cached name from?  You can't get at
the appropriate obstack from the symbol, can you?  Sigh.  I do not
enjoy worrying about memory management when programming in C.)

David Carlton
carlton@kealia.com