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

["Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>]

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.

GDB does _not_ demangle partial symbols, for six years now, due to this change:

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.

And please do _not_ re-add demangling of partial symbols. We gained
a significant speed and time improvement by getting rid of them.

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

> "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