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

[Andrew Cagney <cagney@gnu.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