This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] symtab.c: Fix for infinite GDB recursion in gdb.c++/classes.exp
- To: "Peter.Schauer" <Peter dot Schauer at regent dot e-technik dot tu-muenchen dot de>
- Subject: Re: [RFA] symtab.c: Fix for infinite GDB recursion in gdb.c++/classes.exp
- From: Daniel Berlin <dberlin at redhat dot com>
- Date: 27 Oct 2000 14:59:35 -0400
- Cc: gdb-patches at sourceware dot cygnus dot com
- References: <200010271515.RAA11987@reisser.regent.e-technik.tu-muenchen.de>
"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