[Bug c++/10966] New: Something fishy with constructors

[Bug c++/10966] New: Something fishy with constructors

[ppluzhnikov at google dot com]

There is something fishy going on with constructors.

--- cut ---
struct Foo {
#if DEFAULT_CONSTRUCTOR
  Foo() { x = 0; }
#endif
  Foo(const char *xx) : x(xx) { }
  const char *bar() { return x; }
  const char *x;
};

int main()
{
  Foo f("abc");
  const char *s = f.bar();
}
--- cut ---

g++ -g foo.cc -o foo1
g++ -g foo.cc -o foo2 -DDEFAULT_CONSTRUCTOR



gdb-cvs -nx ./foo1
GNU gdb (GDB) 7.0.50.20091116-cvs
...
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/google/tmp/b1844402/foo1...done.
(gdb) b Foo::bar
Breakpoint 1 at 0x400584: file foo.cc, line 6.
(gdb) b Foo::Foo
(gdb)                 ### problem 1: why didn't this set a breakpoint?



gdb64-cvs -q -nx ./foo2
Reading symbols from /usr/local/google/tmp/b1844402/foo2...done.
(gdb) b Foo::Foo
../../src/gdb/breakpoint.c:4797: internal-error: set_raw_breakpoint: Assertion
`sal.pspace != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.


Both problems also exist in 6.8 and official 7.0 release, though the second
problem does not result in a crash, merely in bogus breakpoints being
inserted:

GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /usr/local/google/tmp/b1844402/foo2...done.
(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)

-- 
           Summary: Something fishy with constructors
           Product: gdb
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: ppluzhnikov at google dot com
        ReportedBy: ppluzhnikov at google dot com
                CC: gdb-prs at sourceware dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://sourceware.org/bugzilla/show_bug.cgi?id=10966

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug c++/10966] Something fishy with constructors

[ppluzhnikov at google dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|                            |1


http://sourceware.org/bugzilla/show_bug.cgi?id=10966

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug c++/10966] Something fishy with constructors

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2009-11-16 18:53 -------
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
> 


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10966

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug c++/10966] Something fishy with constructors

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2009-11-16 19:14 -------
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.


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10966

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug c++/10966] Something fishy with constructors

[keiths at redhat dot com]

------- Additional Comments From keiths at redhat dot com  2009-11-16 19:38 -------
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


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10966

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug c++/10966] Something fishy with constructors

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2009-11-16 20:07 -------
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.  :-)


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10966

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug c++/10966] Something fishy with constructors

[pedro at codesourcery dot com]

------- Additional Comments From pedro at codesourcery dot com  2009-11-16 20:13 -------
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...


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10966

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug c++/10966] Something fishy with constructors

[tromey at redhat dot com]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |11211
              nThis|                            |


http://sourceware.org/bugzilla/show_bug.cgi?id=10966

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug c++/10966] Something fishy with constructors

[tromey at redhat dot com]

------- Additional Comments From tromey at redhat dot com  2010-03-15 17:33 -------
This was fixed by the expr-cumulative/"physname" merge.
I tried both scenarios with cvs head and they seem to work for me.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|7.1                         |7.2


http://sourceware.org/bugzilla/show_bug.cgi?id=10966

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.