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

[Andrew Cagney <cagney at gnu dot org>]

> > 2. We don't include parameter types in mangled names: instead, our
> >    basic lookup routine returns a list of all matches, from which we select
> >    by parameter type or, if that doesn't work, by giving the user a choice.

Isn't this search mechanism required by all languages with overloaded 
methods?

Paul, BTW, look at: The symbol auxilary.
http://sources.redhat.com/ml/gdb/2003-04/msg00017.html

With a per-symbol method, requests for the extra info could be handled 
on-demand (and then added to the symbol aux) without bloating the symbol 
table.

> > 3. Three; there are three reasons:  we don't store demangled names.
> >
> > So, your proposal takes care of 3.  If we could persuade you to
> >
> > A. Provide a mode in which you search for the base name (i.e, return 
> >    the results of your preliminary sift for base names, skipping the
> >    comparison against full demangled name), and
> >
> > B. Provide a mode in which you return ALL matches for a name.
> >
> > ... why we could clean up all that nasty duplication in the ada-* files and
> > join the civilized world.  
>
>
> OK.  (B) has always been on my todo list; C++ would benefit from it
> also.  (A) will require increasing the size of the symbol (because 
> I had been planning to overlap the basename information with the
> demangled name information using a union, and store the two sets
> separately), but I think it's worthwhile.
>
> No promises on timeline, since I'm working on several other projects
> right now, but I'll try to pull this together.
>
> -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer