This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Demangling and searches
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Paul Hilfinger <hilfingr at CS dot Berkeley dot EDU>
- Cc: Elena Zannoni <ezannoni at redhat dot com>, Adam Fedor <fedor at doc dot com>,GDB Patches <gdb at sources dot redhat dot com>
- Date: Tue, 7 Jan 2003 20:03:36 -0500
- Subject: Re: Demangling and searches
- References: <200301072354.PAA18230@tully.CS.Berkeley.EDU>
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