Re: Demangling and searches

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Jan 07, 2003 at 03:54:36PM -0800, Paul Hilfinger wrote:
> 
> 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?
> 
> 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

Bingo.  If you want to get a whiff of what the demangling looks like,
check libiberty/cp-demangle.c; that's just for the GNU v3 mangling
scheme.  cplus-dem.c supports some others.  It's hideously complicated
and includes type information, as part of the language support for
overloading.  If it were just namespace/enclosing class information
this would be practical, but for C++ that's too much.

Ada's "mangling" appears to be much more simplistic.

> rationale behind the current strategy?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer