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

[Paul Hilfinger <hilfingr@gnat.com>]

> I meant lazily demangling the names.  I was wondering if the
> demangling could be done at minsym reading time, or psymtab->symtab
> conversion time, as the other languages do, when there is an

I'd really be very reluctant to do this; it vitiates the entire point
of this "search name" strategy, which was to avoid the storage
requirements of demangled names.  We adopted that strategy quite a few years
ago, due in part to the fact that ACT had customers with LOTS of symbols
and this was a way to save a good deal of symbol space.  

(Side comment: Indeed, until I started to make changes for the public tree,
the ACT version of GDB never even cached demangled names at all, but
instead demangled on the fly into a static area.  One of you (Daniel
or David) objected that this was dangerous, and that we should make
permanent copies of demangled names, which is what gave rise to this
whole caching problem.  Oddly enough, we had never enountered
difficulties as a result of the short lifetimes of our demangled symbols:
it was just a contingent property of GDB that such persistance wasn't
needed.  Nevertheless, I had to agree that it is better not to
rely on a property that is not guaranteed.) 

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

Paul Hilfinger