Re: symtab.h: 2000-10-12 SYMBOL_INIT_DEMANGLED_NAME change, why ?

[Daniel Berlin <dberlin at redhat dot com>]

"Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de> writes:

> > > Minimal symbols are always demangled with language_auto.
> > > Symbol readers make sure that the proper language is used for
> > > SYMBOL_INIT_DEMANGLED_NAME, either via cu_language or via
> > > deduce_language_from_filename.
> > 
> > This is not true anymore.
> > We run into quite a few cases where the language is unknown when
> > symbol_init_demangled_name gets called the first time.
> > 
> > The problem then becomes that when, in the future, the language gets
> > set properly, and symbol_init_demangled_name gets called again, it
> > won't set the demangled name, ever, because we already tried once.
> 
> True.
> But why should it get called again ? Demangling is very exepnsive, so we
> should better take care that we get it right the first time and don't need
> to call it multiple times to finally end up with the proper
> demangling.

There is no noticeable speed decrease due to this change.
I originally thought the  actual likely culprit is somewhere in the stabsreader, the
SYMBOL_LANGUAGE not getting set in all cases.
But it turned out the current file's language was language_unknown for
some reason, at the point it wanted to set the symbol language.
However, I couldn't follow all the codepaths to track this down, due
to the gotos.
I didn't feel like wasting any more time on it, so i just fixed the
symptom, as you said.


> > > So language_unknown should not happen normally, it looks to me like this
> > > change is trying to cure a symptom rather than a cause.
> > 
> > I spent weeks trying to track down the cause, and it appears to only
> > happen in certain versions of gcc. 2.95.2 comes to mind.
> > However, since there will be no 2.95.3, and people still need to be
> > debugging C++ programs, the change is needed anyway.
> 
> We didn't need this change for a couple of years, and I think it is a little
> gross to put it in just to work around a problem in `certain versions of
> gcc. 2.95.2'.
I meant certain versions of gcc, like 2.95.2


--Dan