Summary: | Something fishy with constructors | ||
---|---|---|---|
Product: | gdb | Reporter: | Paul Pluzhnikov <ppluzhnikov> |
Component: | c++ | Assignee: | Paul Pluzhnikov <ppluzhnikov> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gdb-prs, tromey |
Priority: | P2 | ||
Version: | unknown | ||
Target Milestone: | 7.2 | ||
Host: | x86_64-unknown-linux-gnu | Target: | x86_64-unknown-linux-gnu |
Build: | x86_64-unknown-linux-gnu | Last reconfirmed: | |
Bug Depends on: | |||
Bug Blocks: | 11211 |
Description
Paul Pluzhnikov
2009-11-16 18:38:40 UTC
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. |