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

[Paul Hilfinger <hilfingr@gnat.com>]

Daniel,

> 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're right, I did not address this in the patch proper.  I had
prepared a patch in which I used that extra byte in struct symtab to
tag the union and allow an objfile member.  However, I was aware from
correspondence with you that you were working in this area, and that
some of what you proposed to do might eventually allow us to re-do Ada
symbol lookup.  So I decided not to modify the symtab struct for the
moment, and instead submit a patch that would change as little as
possible.  I figured it would be better not to do anything just now
that might interfere with on-going work on the symbol table.

So as an interim measure, I use your suggestion of 21 Jan and first
try to find an objfile via the BFD section.  When that doesn't work, I
simply use a global hashtable to hold the demangled strings.  Yes,
that is a memory leak, but on consideration, I realized that it's only
REALLY a memory leak if (a) I routinely change the entire set of
demangled names numerous times during a single GDB session, or (b)
demangle entirely different, large sets of names each time I reload
the symbol tables.  Yeah, I know, it's not pretty, but again I am hoping
it will ensure that demangled names behave until the next interation of
symtab modifications allow an entirely different strategy.

> 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.

The relevant code now reads

      if (SYMBOL_DEMANGLED_NAME (msym) != NULL)
	add_minsym_to_demangled_hash_table (msym,
                                            objfile->msymbol_demangled_hash);

Ada does demangle; SYMBOL_DEMANGLED_NAME does have to return a
demangled name, if there is one.  Therefore the test here will
precipitate computing and caching the demangled name prematurely (once
symbol_demangled_name is extended to include the Ada case).  This code
also adds the demangled name to the hash table.  But we never look for
demangled names, so that is a waste.

As to your question about how this can work: Ada doesn't really change
your question.  I could just as well ask "How can
SYMBOL_DEMANGLED_NAME work on minimal symbols, given that it doesn't
know what language to use for demangling?" The answer is that if it
quacks like a duck ... excuse me, I mean if ObjC demangling works,
assume you have an ObjC symbol, if C++ demangling works, then assume
it is a C++ symbol, etc., and hope that the demangling schemes don't
collide.  That's what the code says now.  You'll have to argue the 
sensibility of this strategy with others.

> 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.

Yes, I know: you discussed that before and I eagerly await these changes.
For the nonce, I still think I've found a reasonably small hook that 
accomplishes our purposes.

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

Oh, woe: of all your comments, this will be the most difficult to
accommodate.  You see, ACT is full of these confounded Europeans who
insist on single spaces after periods and yell whenever I do things
properly instead.  No doubt they will relent when they hear how this
practice will slow up these patches.  :->).

Paul Hilfinger
Ada Core Technologies, Inc.