Re: problems with gdb

[Srikanth <srikanth at cup dot hp dot com>]

Tom Tromey wrote:
> 
> >>>>> ">" == Srikanth  <srikanth@cup.hp.com> writes:
> 
> >>      The difficulty here is that a name lookup could be
> >> based on either a  demangled name or a mangled name. So unless we
> >> sort the table by both we will have to do linear search. Sorting
> >> the table by both involves heavy penalty at startup, as that
> >> entail three sorts with different keys (PC, demangled name and
> >> mangled name). We eliminated one of the keys : the demangled name
> >> and do a double sort.
> 
> By eliminating this key don't you eliminate a valuable gdb feature?
> 
> Anyway, you can avoid the sort penalty by using a hash table instead.
> You construct the hash table as you read the symbols.  (That's what my
> patch does, as I recall.)
> 
> Tom

Actually no. The table is sorted by mangled name and so if the
user looks up a mangled name we can use binary search. 

	On the other hand if the user uses a source level name
such as "break Class::Method", we mangle it *on the fly* and
use the mangled name as a search key.

	The make or break question here whether given a
partial string like Class::Method (where we don't have 
any parameter information which is part of the mangled
signature), we can always compute the prefix of the 
mangled signature. This is highly dependant on your
compiler's name mangling scheme. 

	If you could (we could in the case of HP ANSI C++ compiler)
then you can use the prefix as the search key in a slightly
modified binary search, zoom in on the set of the symbols
with the identical prefix, demangle only them just in time and 
do a full compare. 

Srikanth