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

[Daniel Jacobowitz <drow@false.org>]

On Fri, Mar 05, 2004 at 05:39:25AM -0500, Paul Hilfinger wrote:
> 
> 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.

I'm not sure what others will think of this interim measure.  I don't
like it much, though.

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

What you did not explain is how this is supposed to be different from
SYMBOL_SEARCH_NAME.

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

The existing ada_demangle never fails.  How does that interact with
what you said above?  Hopefully not by tagging all minsyms as Ada!

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer