[RFA] Introduce notion of "search name"

[Daniel Jacobowitz]

On Tue, Apr 06, 2004 at 09:35:16AM -0500, Jim Blandy wrote:
> 
> Paul Hilfinger <hilfingr@gnat.com> writes:
> > Do you really object to our simply making permanent copies of these
> > names as needed?  (I'm perfectly happy to ditch the kludgy
> > objfile-finding hack.) You can't expect to save any space by
> > reclaiming these demangled names space when you reload the symbol
> > file, because (as I argued before) the set of demangled names
> > generally doesn't change much in such cases, and we are "interning"
> > the demangled symbols, so that multiple computations of the same
> > demangled symbol don't increase space.  This particular choice of name
> > storage is confined to the Ada module (the symbol table module doesn't
> > apply free to names stored in symbols, partial symbols, or minimal
> > symbols, so it doesn't care if one them has a longer than necessary
> > lifetime).
> 
> I tend to think it's not ideal, but okay.  Daniel, you were unhappy
> with this; did you have suggestions?

I'm unhappy with it, partly because not having a lifetime for these
things make it harder to identify memory leaks (of which we already
have quite enough, thank you).  But there are two options:

  - decide that lazily demangling is useful, and arrange to pass
    an objfile to every call to SYMBOL_DEMANGLED_NAME.  This also
    affects, at least, SYMBOL_NATURAL_NAME and SYMBOL_PRINT_NAME.
    I think it wouldn't be hard, just messy.
  - decide that being picky about the storage lifetime doesn't matter,
    and Paul's approximation is good enough.

I'm happier with the global hash table than I am with kludging around
searching for an objfile, certainly.  What do you think of the options?

On Fri, Apr 02, 2004 at 03:29:55AM -0500, Paul Hilfinger wrote:
> > What you did not explain is how [SYMBOL_DEMANGLED_SEARCH_NAME] 
> > is supposed to be different from SYMBOL_SEARCH_NAME.
> 
> Well, the direct answer is that for Ada, 
>       SYMBOL_DEMANGLED_SEARCH_NAME (sym) == NULL
> whereas 
>       SYMBOL_SEARCH_NAME (sym) == the "linkage name" of the symbol
> Perhaps, now that you bring it up, it might be clearer simply to make
> this a predicate: 
>       SYMBOL_SEARCHED_BY_DEMANGLED_NAME (sym) 
> or something like that?

I don't think that either of those divisions is general enough to be
useful.  Why should the search name have to be the linkage name or the
demangled name?  For C++ there are two potential 'search names' - the
name without DMGL_PARAMS, or just the basename.  Neither of these is
the linkage or natural name.

> > The existing ada_demangle never fails.  How does that interact with
> > what you said above?  Hopefully not by tagging all minsyms as Ada!
> 
> Ah, I have been putting off syncing the ada-* files with ours (they
> aren't compiled at the moment, and I feel no need to clutter the 
> public file system with unused versions.  However, perhaps it's time to
> check in the current versions, which are considerably different from the
> snapshot that's currently there.  In short: you are quite right, and the
> current Ada demangler returns NULL for non-Ada-mangled symbols.

Perhaps it's time to do this again.  I'm not sure how to handle it.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer