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

[Paul Hilfinger <hilfingr at gnat dot com>]

Daniel,

So where do we stand on all this?  I've been off on other things for a bit,
but I'd like to get the issues surrounding this patch settled.  

I understand your concern about memory leaks, but I've suggested why
first, these can be at least a contained problem, and second,
why in any case there's good reason to think my strategy doesn't really 
result in "leaks"---in the sense of garbage that never gets re-used.

I do admit that the changes you have been working on (at least as I
understand them from your remarks) might make it necessary (or at
least advisable) to do some considerable revision, but at the moment
we'd really like to start getting the ACT stuff activated in the
public version, even if we have to revisit certain parts later.

Paul Hilfinger

> Paul Hilfinger <hilfingr@gnat.com> writes:
> > > 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?
> > 
> > If leaking is your concern, how about this: I'll arrange our global
> > hash table for demangled names to store the strings themselves in a
> > a corresponding global obstack.  That way, the total amount of memory devoted 
> > to this particular set of demangled names is easy to monitor.  
> > 
> > There are a few opportunities, I suppose, to clear the whole thing,
> > such as when someone executes 'file' or 'symbol-file' (with no
> > arguments).  Not sure if they're worth exploiting.
> > 
> > > > 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.
> > 
> > I don't think that's a problem.  I'll take another stylistic pass over
> > the Ada sources and then just check in our current versions. Since
> > they aren't compiled (yet), they can't break anything, after all.
> 
> Daniel, you've got higher standards on this issue than I do, but I'd
> like to see your standards prevail.  If you and Paul can work out
> something, then I'll approve of it.
>