This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Demangling and searches
- From: Elena Zannoni <ezannoni at redhat 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>, Daniel Jacobowitz <drow at mvista dot com>
- Date: Tue, 7 Jan 2003 20:43:40 -0500
- Subject: Re: Demangling and searches
- References: <200301072354.PAA18230@tully.CS.Berkeley.EDU>
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