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

Andrew Cagney
2004-01-23T21:08:25Z

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