Bug 10966

Subject: Re:  New: Something fishy with constructors

> (gdb) b Foo::Foo
> Breakpoint 1 at 0x0
> Note: breakpoint 1 also set at pc 0x0.
> Breakpoint 2 at 0x0
> warning: Multiple breakpoints were set.
> Use the "delete" command to delete unwanted breakpoints.
> (gdb)
> 

Ah!  This is actually PR8166, in desguise.  'show multiple-symbols' was
added in gdb 7.0, and the default changed to "all":

On head:

(gdb) show multiple-symbols
How the debugger handles ambiguities in expressions is "all".

(gdb) b Foo::Foo
[0] cancel
[1] all
?HERE
?HERE
> 

Subject: Re:  Something fishy with constructors

Here's the problem:

(top-gdb) bt
#0  add_matching_methods (method_counter=0, t=0xc73930, language=language_cplus, sym_arr=0x7fff4c0b26e0)
    at ../../src/gdb/linespec.c:316
#1  0x0000000000536b72 in find_methods (t=0xc73930, name=0x7fff4c0b2830 "Foo", language=language_cplus,
    sym_arr=0x7fff4c0b26e0) at ../../src/gdb/linespec.c:249
#2  0x00000000005392cb in find_method (funfirstline=1, canonical=0x7fff4c0b2ce8, saved_arg=0xb1e1c2 "Foo::Foo",
    copy=0x7fff4c0b2830 "Foo", t=0xc73930, sym_class=0xc8b840, not_found_ptr=0x7fff4c0b2d14)
    at ../../src/gdb/linespec.c:1488
#3  0x0000000000538e99 in decode_compound (argptr=0x7fff4c0b2c00, funfirstline=1, canonical=0x7fff4c0b2ce8,
    saved_arg=0xb1e1c2 "Foo::Foo", p=0xb1e1ca "", not_found_ptr=0x7fff4c0b2d14) at ../../src/gdb/linespec.c:1386


linespec.c:

312           sym_arr[i1] = lookup_symbol_in_language (phys_name,
313                                        NULL, VAR_DOMAIN,
314                                        language,
315                                        (int *) NULL);
316           if (sym_arr[i1])    <<<<<<<<<<
317             i1++;
318           else

(top-gdb) p *sym_arr[i1]
$2 = {ginfo = {name = 0xc739a0 "Foo", value = {ivalue = 0, block = 0x0, bytes = 0x0, address = 0, chain = 0x0},
    language_specific = {cplus_specific = {demangled_name = 0x0}}, language = language_cplus, section = 0,
    obj_section = 0x0}, type = 0xc73930, symtab = 0xc954e0, domain = STRUCT_DOMAIN, aclass = LOC_TYPEDEF,
  is_argument = 0, is_inlined = 0, line = 1, ops = {ops_computed = 0x0, ops_register = 0x0}, aux_value = 0x0,
  hash_next = 0xc8ba00}

(top-gdb) p phys_name
$3 = 0xc6f0de "Foo"

'phys_name' isn't the link name of neither 'Foo::Foo()' nor
'Foo::Foo(const char *)', (those would be _ZN3FooC1Ev and _ZN3FooC2Ev) so
looking up on VAR_DOMAIN for "Foo" happens to find the typedef for
struct FOO instead of a FOO's methods (those have VAR_DOMAIN;LOC_BLOCK)...

To see what's going on with non-constructors, I've added these to
struct Foo in the test case:

  void Bar();
  void Bar(const char *);

and here's what you get at the same place in the code:

(gdb) b Foo::Bar
(top-gdb) p phys_name
$4 = 0xc6f11f "_ZN3Foo3BarEPKc"
(top-gdb) p *sym_arr[i1]
$5 = {ginfo = {name = 0xc536f0 "_ZN3Foo3BarEPKc", value = {ivalue = 13161920, block = 0xc8d5c0,
      bytes = 0xc8d5c0 "\230\005@", address = 13161920, chain = 0xc8d5c0}, language_specific = {cplus_specific = {
        demangled_name = 0xc53700 "Foo::Bar(char const*)"}}, language = language_cplus, section = 12,
    obj_section = 0xc53280}, type = 0xc8d380, symtab = 0xc954e0, domain = VAR_DOMAIN, aclass = LOC_BLOCK,
  is_argument = 0, is_inlined = 0, line = 24, ops = {ops_computed = 0x7a1ce0, ops_register = 0x7a1ce0},
  aux_value = 0xc8d4a0, hash_next = 0xc8d6f0}

I'd guess that at least, something would have to be done
so that 'phys_name' on Foo's constructors is the proper
mangled name.

I wonder if archer-keiths-expr-cumulative archer branch has
a not-too-big-and-invasive fix for this.  I think that they
don't use mangled names anymore on that branch, so if fixed,
it may not be a small change though.

Subject: Re:  Something fishy with constructors

On 11/16/2009 11:14 AM, pedro at codesourcery dot com wrote:
> I wonder if archer-keiths-expr-cumulative archer branch has
> a not-too-big-and-invasive fix for this.  I think that they
> don't use mangled names anymore on that branch, so if fixed,
> it may not be a small change though.

expr-cumulative should fix (some/all of?) these problems. Running the 
provided examples, I get:

$ ./gdb -nx -q ~/tmp/foo1
Reading symbols from /home/keiths/tmp/foo1...done.
(gdb) b Foo::Foo
Breakpoint 1 at 0x804847b: file foo.cc, line 5.

and

$ ./gdb -nx -q ~/tmp/foo2
Reading symbols from /home/keiths/tmp/foo2...done.
(gdb) b Foo::Foo
Breakpoint 1 at 0x804847b: file foo.cc, line 5.


I am working to get all these patches submitted upstream right now. I 
have, I think, one miscellaneous patch (which is actually Daniel's 
patch), and some ADA failures to investigate. When that's done, I will 
be ready to submit my "mega-patch" from expr-cumulative to get rid of 
linkage_name.

Keith

Subject: Re:  Something fishy with constructors

On Monday 16 November 2009 19:38:18, keiths at redhat dot com wrote:

> expr-cumulative should fix (some/all of?) these problems.

Great!

> I am working to get all these patches submitted upstream right now. I 
> have, I think, one miscellaneous patch (which is actually Daniel's 
> patch), and some ADA failures to investigate. When that's done, I will 
> be ready to submit my "mega-patch" from expr-cumulative to get rid of 
> linkage_name.

Looking forward for that!

If the new crash bothers people meanwhile, I suppose we could do
a quick bandaid like:

 - Have add_matching_methods call lookup_symbol_in_language
   with FUNCTIONS_DOMAIN (and make that work) instead of
   VAR_DOMAIN.  That still looks up for "Foo" multiple
   times, so 'b Foo::Foo' would still display multiple entries
   for the same constructor...

 - Alternatively, do something like:

add_matching_methods:

      sym_arr[i1] = lookup_symbol_in_language (phys_name,
				   NULL, FUNCTIONS_DOMAIN,
				   language,
				   (int *) NULL);
-      if (sym_arr[i1])
+      /* See PR10966.  Remove check on symbol domain and class when
+         we stop using (bad) linkage names on constructors.  */
+      if (sym_arr[i1] && (SYMBOL_DOMAIN (sym_arr[i1]) == VAR_DOMAIN
+                          && SYMBOL_CLASS (sym_arr[i1]) == LOC_BLOCK))
	i1++;

   That is, simply ignore bad lookups...

Or just wait --- I'm fine with that.  :-)

Subject: Re:  Something fishy with constructors

On Monday 16 November 2009 18:53:42, pedro at codesourcery dot com wrote:
> On head:
> 
> (gdb) show multiple-symbols
> How the debugger handles ambiguities in expressions is "all".
> 
> (gdb) b Foo::Foo
> [0] cancel
> [1] all
> ?HERE
> ?HERE
> > 

For completeness: I forgot to paste the '(gdb) set multiple-symbols ask'
right before 'b Foo::Foo' that I had typed in the console, so
that head does ask...

This was fixed by the expr-cumulative/"physname" merge.
I tried both scenarios with cvs head and they seem to work for me.