[Bug symtab/17602] New: iterate_name_matcher passes arguments to strcmp_iw in reverse order?

["dje at google dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=17602

            Bug ID: 17602
           Summary: iterate_name_matcher passes arguments to strcmp_iw in
                    reverse order?
           Product: gdb
           Version: 7.8
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: dje at google dot com

Seems like this bug would have been found by now, so I don't have enough
confidence in my assessment.  Something is not right, however, so I'm writing
this down.

With the attached patch to the gdb.cp/anon-ns.{cc,exp} testcase to move the
guts of the test out of the CU with main (because gdb expands the symtab with
main at the start and thus partial symtabs / .gdb_index are not exercised),
I'm seeing odd behaviour.

bash$ make run
(gdb) file testsuite/gdb.cp/anon-ns
(gdb) set debug symfile on
(gdb) b (anonymous namespace)::doit1(void)
qf->lookup_symbol (anon-ns, 0, "(anonymous namespace)", VAR_DOMAIN)
qf->lookup_symbol (...) = NULL
qf->lookup_symbol (anon-ns, 0, "(anonymous namespace)", VAR_DOMAIN)
qf->lookup_symbol (...) = NULL
qf->lookup_symbol (anon-ns, 1, "(anonymous namespace)", VAR_DOMAIN)
qf->lookup_symbol (...) = NULL
qf->lookup_symbol (anon-ns, 0, "(anonymous namespace)::doit1", VAR_DOMAIN)
qf->lookup_symbol (...) = NULL
qf->lookup_symbol (anon-ns, 0, "(anonymous namespace)", VAR_DOMAIN)
qf->lookup_symbol (...) = NULL
qf->lookup_symbol (anon-ns, 0, "(anonymous namespace)::doit1", VAR_DOMAIN)
qf->lookup_symbol (...) = NULL
qf->lookup_symbol (anon-ns, 0, "(anonymous namespace)", VAR_DOMAIN)
qf->lookup_symbol (...) = NULL
qf->lookup_symbol (anon-ns, 1, "(anonymous namespace)::doit1", VAR_DOMAIN)
qf->lookup_symbol (...) = NULL
qf->expand_symtabs_matching (anon-ns, 0x0, 0x5f976f, ALL_DOMAIN,
0x7fffb8652900)
qf->find_pc_sect_symtab (anon-ns, 0x237f7d0, 0x400620, 0x0, 1)
qf->find_pc_sect_symtab (...) =
../../../anonymous-namespace/gdb/testsuite/gdb.cp/anon-ns2.cc
qf->find_pc_sect_symtab (anon-ns, 0x237f7d0, 0x400620, 0x236ade0, 0)
qf->find_pc_sect_symtab (...) =
../../../anonymous-namespace/gdb/testsuite/gdb.cp/anon-ns2.cc
qf->find_pc_sect_symtab (anon-ns, 0x237f7d0, 0x400620, 0x236ade0, 0)
qf->find_pc_sect_symtab (...) =
../../../anonymous-namespace/gdb/testsuite/gdb.cp/anon-ns2.cc
qf->find_pc_sect_symtab (anon-ns, 0x237f7d0, 0x400620, 0x236ade0, 0)
qf->find_pc_sect_symtab (...) =
../../../anonymous-namespace/gdb/testsuite/gdb.cp/anon-ns2.cc
qf->find_pc_sect_symtab (anon-ns, 0x237f7d0, 0x400620, 0x0, 0)
qf->find_pc_sect_symtab (...) =
../../../anonymous-namespace/gdb/testsuite/gdb.cp/anon-ns2.cc
qf->find_pc_sect_symtab (anon-ns, 0x237f7d0, 0x400624, 0x0, 0)
qf->find_pc_sect_symtab (...) =
../../../anonymous-namespace/gdb/testsuite/gdb.cp/anon-ns2.cc
qf->find_pc_sect_symtab (anon-ns, 0x237f7d0, 0x400620, 0x0, 0)
qf->find_pc_sect_symtab (...) =
../../../anonymous-namespace/gdb/testsuite/gdb.cp/anon-ns2.cc
qf->find_pc_sect_symtab (anon-ns, 0x237f7d0, 0x400620, 0x0, 0)
qf->find_pc_sect_symtab (...) =
../../../anonymous-namespace/gdb/testsuite/gdb.cp/anon-ns2.cc
qf->find_pc_sect_symtab (anon-ns, 0x237f7d0, 0x400624, 0x236ade0, 0)
qf->find_pc_sect_symtab (...) =
../../../anonymous-namespace/gdb/testsuite/gdb.cp/anon-ns2.cc
qf->find_pc_sect_symtab (anon-ns, 0x237f7d0, 0x400624, 0x236ade0, 0)
qf->find_pc_sect_symtab (...) =
../../../anonymous-namespace/gdb/testsuite/gdb.cp/anon-ns2.cc

Breakpoint 1 at 0x400624: file
../../../anonymous-namespace/gdb/testsuite/gdb.cp/anon-ns2.cc, line 24.
(gdb) 

Note that the calls to qf->lookup_symbol all fail, and yet the breakpoint
succeeds!  [btw, the calls to qf->lookup_symbol are all for the call to 
cp_canonicalize_string_no_typedefs in find_linespec_symbols]

Note: the call to qf->expand_symtabs_matching is a no-op.

This is because in addition to trying the debug info we also try minsyms.
We find the symbol in minsyms, that gets us an address.  We then pass the
address to qf->find_pc_sect_symtab and that will cause the debug info for the
relevant compunit to be expanded, and thus the breakpoint succeeds.

One problem (the problem?) is that in the call to strcmp_iw in
iterate_name_matcher, the arguments are reversed.
It's the first argument that gets special "(" handling,
but we're calling it with entries from gdb_index (which don't have overload
information) in the first argument and the canonicalized user-specified
breakpoint address in the second argument (which can have overload
information).

-- 
You are receiving this mail because:
You are on the CC list for the bug.