This is the mail archive of the gdb-prs@sourceware.org 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]
Other format: [Raw text]

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


------- 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.


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