This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] Introduce notion of "search name"


On Wed, Mar 03, 2004 at 02:15:50PM -0500, Paul Hilfinger wrote:
> 
> The following patch does nothing except to prepare the way for some later
> Ada modifications by providing a few "hooks". I've discussed this 
> modification earlier on this newsgroup.  At the moment, I've given
> the definitions placeholder definitions that simply result in the
> current semantics.  I propose to change them when Ada support is turned on.
> 
> The idea is to define "search name" as "the name that a language
> module uses when searching for this symbol".  As discussed earlier,
> the search name would be normally be the natural name, but in the case
> of Ada, would just be the linkage name.
> 
> The modification to the signature of symbol_natural_name is to allow the
> option of delayed (lazy) evaluation of the demangled name, which is
> actually the point of introducing search names.

I'm no symtab maintainer, but I've had my hands in this code lately, so
I have a couple of comments anyway.  There are some of things I don't
like about this patch, unfortunately.


It doesn't address on of the thornier problems I hit when doing the
same thing, namely that of allocation.  OK, someone uses
SYMBOL_DEMANGLED_NAME, we lazily allocate a demangled name - where? The
objfile is not available.  I think there may be no option but to
pass the objfile to SYMBOL_DEMANGLED_NAME.  What did you do for Ada?


You define SYMBOL_DEMANGLED_SEARCH_NAME.  What's it really good for,
and how does it do any good?  You only use it for the minimal symbol
hash tables; the fundamental problem with minimal symbols is that we
don't know their language, so I don't know how you can reliably make a
language-specific decision like this one.

SYMBOL_DEMANGLED_SEARCH_NAME also codifies more than necessary of the
difference between the other SYMBOL_*_NAME macros and
SYMBOL_SEARCH_NAME.  Something that I think may be useful is to use
just the basename for the search name and then have language-specific
code to cherry-pick the resulting matches afterwards; one big advantage
of this is that it lets me sidestep the Java vs. C++ demangling issues.
I suspect it is possible (for all supported languages) to unambiguously
and efficiently identify the basename. I need to look at some of the
other in-use manglings to follow up on that idea though, particularly
g++ v2 and ObjC.

This idea may only be workable for minimal symbols, because of the
namespace inference hacks we use for C++.


Oh, and two spaces after a full stop in comments.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]