Re: Demangling and searches

[Elena Zannoni <ezannoni at redhat dot com>]

Paul Hilfinger writes:
 > 
 > For some time, I've been meaning to ask a basic question about GDB
 > search strategy: for language implementations that mangle their
 > identifiers, the standard procedure in GDB at the moment is to search
 > for the demangled identifier among the demangled identifiers of the
 > symbol table, and to speed this search up by precomputing and storing
 > the demangled symbol names.  Why?
 > 

Gdb did that orginally for c++. In October 2000 the behavior was
changed to do the search among the demangled names instead of the
mangled ones. This way it was able to do a binary search instead of a
linear one, given that the names are sorted on the demangled value.
I think that what prompted the change was this analysis:
http://sources.redhat.com/ml/gdb-patches/2000-06/msg00024.html

Unfortunately there is still some lack of clarity around the partial
symbol handling. As David Carlton mentions. Partial symbols don't
store the demangled names. 

Elena


 > We used to do that for Ada mode in GDB, but subsequently changed our
 > approach entirely.  For Ada, we MANGLE the symbol we're searching for
 > and then search among the MANGLED (i.e., raw, unmodified, warm-from-
 > the-executable) names.  We do very little demangling as a result, and
 > do not devote any storage to demangled names.  Of course, we do have
 > to demangle during the 'info XXX' symbol searches, but that is not a
 > common operation (at least for our customers), and therefore we saw
 > little to be gained by storing the demangled names.
 > 
 > Is there some unfortunate feature of C++ and ObjC mangling that
 > completely prevents our approach for those languages?  What was the
 > rationale behind the current strategy?
 > 
 > Thanks for the information.
 > 
 > Paul Hilfinger