10966 2009-11-16 18:38:00 +0000 Something fishy with constructors 2010-03-15 17:33:48 +0000 1 1 1 Unclassified gdb c++ unknown All All RESOLVED FIXED P2 normal 7.2 11211 1 ppluzhnikov ppluzhnikov gdb-prs tromey x86_64-unknown-linux-gnu x86_64-unknown-linux-gnu x86_64-unknown-linux-gnu oldest_to_newest 39817 0 ppluzhnikov 2009-11-16 18:38:40 +0000 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) 39818 1 palves 2009-11-16 18:53:42 +0000 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 > 39820 2 palves 2009-11-16 19:14:06 +0000 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. 39822 3 keiths 2009-11-16 19:38:18 +0000 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 39825 4 palves 2009-11-16 20:07:04 +0000 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. :-) 39827 5 palves 2009-11-16 20:13:31 +0000 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... 42024 6 tromey 2010-03-15 17:33:48 +0000 This was fixed by the expr-cumulative/"physname" merge. I tried both scenarios with cvs head and they seem to work for me.