[RFA] symtab.c: Fix for infinite GDB recursion in gdb.c++/classes.exp

[Daniel Berlin]

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

> >From lookup_symbol_aux:
> 
>           else if (MSYMBOL_TYPE (msymbol) != mst_text
>                    && MSYMBOL_TYPE (msymbol) != mst_file_text
>                    && !STREQ (name, SYMBOL_NAME (msymbol)))
>             {
>               /* This is a mangled variable, look it up by its
>                  mangled name.  */
>               return lookup_symbol_aux (SYMBOL_NAME (msymbol), block,
>                                         namespace, is_a_field_of_this, symtab);
>             }
> 

> Dan, I'm sorry, but your changes to symtab.c show, that you are indeed
> confused with respect to the mangling of partial symbols.
> 
No, i'm not actually.  If partial symbols don't get converted to
symtabs at the right time, because of some dependency on mangled
names, that's a different problem than I solved, and a bug i wasn't
aware of.

> GDB does _not_ demangle partial symbols, for six years now, due to this change:
> 
Nor should it. It would be pointless.
> Sat Oct  8 04:27:21 1994  Peter Schauer  (pes@regent.e-technik.tu-muenchen.de)
> 
>         Speed up GDB startup time by not demangling partial symbols.
> 
> Your changes to always look up demangled symbols will therefore never find
> any demangled partial symbols, because the demangled name is not stored
> in the psymbol.



> Unfortunately this is not covered by the testsuite, but I will try to come
> up with an example.
You won't be able to, we convert psymtabs to symtabs too often, so
you'd have to find a way to have it not do the conversion for your
particular psymtab.

> 
> And please do _not_ re-add demangling of partial symbols. We gained
> a significant speed and time improvement by getting rid of them.
This was years ago.
But i'm not suggesting we should re-add it.
Just pass the mangled name into lookup_partial_symbol.

> 
> I think that this could be fixed by passing the mangled name as well to
> lookup_symbol_aux and use that for lookup_partial_symbol, together with
> cleaning up lookup_partial_symbol and compare_psymbols and adding the
> appropriate comments. 

compare_psymbols isn't broken, SYMBOL_SOURCE_NAME first looks for the
demangled name, and falls back on the mangled one if it can't find it.
>I still have to think a little bit more about all the
> implications though, it has been a long time that I had to do any debugging
> in this part of GDB.

It'd be nice if someone had mentioned this problem of everything
*except* partial symbols being able to be looked up by demangled name,
before hand.
and if someone had a testcase to make it not work, so i would have noticed.


> 
> > "Peter.Schauer" <Peter.Schauer@regent.e-technik.tu-muenchen.de> writes:
> > 
> > > Current CVS GDB gets into an infinite recursion in gdb.c++/classes.exp
> > > (print Foo::st) if a stock gcc-2.95.2 with DWARF2 debugging info is used
> > > on Solaris and Linux x86.
> > > 
> > > The scenario is as follows:
> > > 
> > > lookup_symbol is called with a request for Foo::st, we find a matching
> > > minimal symbol, detect that it is a mangled variable and call lookup_symbol
> > > with the mangled name. Then lookup_symbol demangles the mangled name again,
> > > calls lookup_symbol with Foo::st and off we go till the stack overflows.
> > 
> > Even though the fix is technically correct, i'm puzzled.
> > It's clearly *not* a mangled variable, why is it thinking it is?
> > --Dan
> 
> -- 
> Peter Schauer			pes@regent.e-technik.tu-muenchen.de