This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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

> > > 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.
> 
> The following comment from symtab.c:lookup_partial_symbol made me think that
> you didn't realize that partial symbols are not demangled:
> 
>       /* djb - 2000-06-03 - Use SYMBOL_MATCHES_NAME, not a strcmp, so
>          we don't have to force a linear search on C++. Probably holds true
>          for JAVA as well, no way to check.*/
> 
> This is misleading, as SYMBOL_MATCHES_NAME has no different effect to a
> strcmp, as SYMBOL_DEMANGLED_NAME is always NULL in a partial symbol.
>
 
> And later on you write:
> 
> > 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.
> 
> which also shows that you didn't understand the problem back then.

I didn't realize there was a problem, yes.

> 
> I'd suggest to get rid of any references to SYMBOL_SOURCE_NAME etc. in partial
> symbol handling and add comments that clearly state that partial symbols
> have no demangled names.
Well, eventually partial symbols are going away in general (they'll
become part of hte stabs reader, where they belong, since things like
DWARF2 have the indexes that partial symbols are  solving for STABS),
so it might not be worth it to even bother right now.


> 
> > > 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.
> 
> OK, it took me some time, but how about this:
> 
> Apply this patch
> 
> *** /users/pes/gdbnd/devo/gdb/testsuite/gdb.c++/misc.cc Sat Aug  5 11:38:51 2000
> --- misc.cc     Sat Oct 28 12:44:51 2000
> ***************
> *** 386,391 ****
> --- 386,398 ----
>     operator int ();
>     int times (int y);
>   };
> + class Aoo
> + {
> +  public:
> +    Aoo() {}
> +    static int st;
> + };
> + int Aoo::st = 400;
> 
>   class Bar : public Base1, public Foo {
>    public:
> 
> and use a stock gcc-2.95.2 with stabs debugging to compile it.
> 
> A GDB _without_ your changes does this:
> 
> pes@eno_2040$ gcc -g misc.cc
> pes@eno_2041$ gdb-000915 a.out
> GNU gdb 20000915
> Copyright 2000 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-pc-solaris2.6"...
> (gdb) i var Aoo::st
> All variables matching regular expression "Aoo::st":
> 
> File misc.cc:
> int Aoo::st;
> 
> _With_ your changes I get the following (after applying my suggested fix,
> otherwise you will get a core dump):
> 
> pes@eno_2042$ gdb-001025 a.out
> GNU gdb 20001025
> Copyright 2000 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-pc-solaris2.6"...
> (gdb) i var Aoo::st
> Internal: global symbol `_3Aoo.st' found in misc.cc psymtab but not in symtab.
> _3Aoo.st may be an inlined function, or may be a template function
> (if a template, try specifying an instantiation: _3Aoo.st<type>).

Bingo.
Do you have a copyright assignment on file, so i can add your case to
the testsuite?

> 
> > > 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 didn't say it is broken, I just think that the change is misleading,
> see comments for cleaning up lookup_partial_symbol above.
> 
> > Just pass the mangled name into lookup_partial_symbol.
> 
> Yes, I think that's the way to go, in addition to fixing the infinite
> recursion.
> 
> Will you take care of it ?

Yup.

Thanks for noticing the problem.
--Dan
> 
> -- 
> Peter Schauer			pes@regent.e-technik.tu-muenchen.de


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]