With the appended testcase, I get the following: $ g++ --version g++ (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4) [...] $ g++ -g foo.cc foo2.cc $ ./gdb -nx ./a.out GNU gdb (GDB) 7.1.50.20100619-cvs [...] (gdb) start [...] (gdb) b 'c::foo()' the class c does not have any method named foo() Hint: try 'c::foo()<TAB> or 'c::foo()<ESC-?> (Note leading single quote.) Make breakpoint pending on future shared library load? (y or [n]) This is a regression from 7.1. fyi, the following does work: (gdb) b c::foo # Do this first ... (gdb) b c::foo() # ... and then this works. --- foo.h: class c { public: void foo (); }; --- foo.cc: #include "foo.h" int main () { c* p = new c; p->foo (); return 0; } --- foo2.cc: #include "foo.h" void c::foo () { }
I've looked at this a bit, and here is what I've discovered. This bug occurs as a result of the dwarf2_physname patch committed (by me) several months ago. The problem is not really that dwarf2_physname is being used, however. The problem is that this never really worked to begin with; it just appeared to! For the method "void c::foo()", partial_die_full_name will store the name "c::foo" into the partial symbol. When the dwarf information for class "c" is expanded (since gdb will first look for the symtab for "c" so that it can search for the method "foo()"), it calls dwarf2_physname to build the physname of the method. This is "c::foo()" (=TYPE_FN_FIELD_PHYSNAME). Now we look for "c::foo()". gdb searches through the list of partial symbols. But since partial_die_full_name has stored "c::foo", the psymtab search fails. [This behavior is in all versions of gdb.] gdb tries to fallback to comparing the linkage name (after demangling it), and since gdb 7.1, we no longer store/use linkage names (from DW_AT_MIPS_linkage_name) for C++/Java, this fallback search also fails, and the symbol is now no longer found. If you manage to expand the psymtab before searching, then the search of the symtabs will successfully find "c::foo()", since that is exactly the name that is stored in the full symbol (from dwarf2_physname). I am investigating solutions now. I hope to have a patch for this shortly.
Patch submitted (http://sourceware.org/ml/gdb-patches/2010-06/msg00467.html)
I have applied the patch to the debian version 7.2-1. For setting a breakpoint on a method it doesn't help. Sources: class3.h: #ifndef __CLASS3_H__ #define __CLASS3_H__ class class3 { private: int intval; public: class3(int intVal); void f1(const int iMsgId); }; #endif class3.cc: #include "class3.h" #include <iostream> using namespace std; class3::class3(int intVal) { intval = intVal; } void class3::f1(const int iMsgId) { cout << "f1" << " with " << iMsgId << endl; } main3.cc: #include "class3.h" int main(int argc, char *argv[]) { class3 c3(47); const int msgId = 4711; c3.f1(msgId); } compilation: make c3test g++ -g -c -o class3.o class3.cc g++ -g -c -o main3.o main3.cc g++ -g class3.o main3.o -o c3test running gdb: gdb c3test GNU gdb (GDB) 7.2-debian ... (gdb) b class3::f1 the class class3 does not have any method named f1 Hint: try 'class3::f1<TAB> or 'class3::f1<ESC-?> (Note leading single quote.) Make breakpoint pending on future shared library load? (y or [n]) n (gdb) b class3::f1(int) the class class3 does not have any method named f1(int) Hint: try 'class3::f1(int)<TAB> or 'class3::f1(int)<ESC-?> (Note leading single quote.) Make breakpoint pending on future shared library load? (y or [n]) n (gdb) I actually ran into this using a real world example. Some breakpoints on some methods can be set. Trying to narrow it down, I came up with the above example. Without the patch the behaviour is the same.
(In reply to comment #3) > I have applied the patch to the debian version 7.2-1. > For setting a breakpoint on a method it doesn't help. Thank you for the feedback. Unfortunately, the problem you've reported here is not really the same bug: > #ifndef __CLASS3_H__ > #define __CLASS3_H__ > > class class3 > { > private: > int intval; > > public: > class3(int intVal); > > void f1(const int iMsgId); > }; > #endif If you declare f1 to take "int" instead of "const int", it all works. I believe this is a compiler bug, but there might be a way to workaround it in gdb. I've filed c++/12328 to track this. If you find any other test cases that exhibit the problem, please submit it here so that I can take a look.
CVSROOT: /cvs/src Module name: src Changes by: kseitz@sourceware.org 2011-03-16 21:08:57 Modified files: gdb/testsuite : ChangeLog Added files: gdb/testsuite/gdb.cp: cmpd-minsyms.cc cmpd-minsyms.exp ovsrch1.cc ovsrch2.cc ovsrch3.cc ovsrch4.cc ovsrch.exp ovsrch.h Log message: PR c++/12273 * gdb.cp/cmpd-minsyms.exp: New test. * gdb.cp/cmpd-minsyms.cc: New file. PR c++/11734 * gdb.cp/ovsrch.exp: New test. * gdb.cp/ovsrch.h: New file. * gdb.cp/ovsrch1.cc: New file. * gdb.cp/ovsrch2.cc: New file. * gdb.cp/ovsrch3.cc: New file. * gdb.cp/ovsrch4.cc: New file. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/ChangeLog.diff?cvsroot=src&r1=1.2636&r2=1.2637 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.cp/cmpd-minsyms.cc.diff?cvsroot=src&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.cp/cmpd-minsyms.exp.diff?cvsroot=src&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.cp/ovsrch1.cc.diff?cvsroot=src&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.cp/ovsrch2.cc.diff?cvsroot=src&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.cp/ovsrch3.cc.diff?cvsroot=src&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.cp/ovsrch4.cc.diff?cvsroot=src&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.cp/ovsrch.exp.diff?cvsroot=src&r1=NONE&r2=1.1 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/testsuite/gdb.cp/ovsrch.h.diff?cvsroot=src&r1=NONE&r2=1.1
CVSROOT: /cvs/src Module name: src Changes by: kseitz@sourceware.org 2011-03-16 21:12:13 Modified files: gdb : ChangeLog linespec.c psymtab.c gdb/cli : cli-utils.h cli-utils.c Log message: * linespec.c (find_methods): Canonicalize NAME before looking up the symbol. (name_end): New function. (keep_name_info): New function. (decode_line_1): Use keep_name_info. (decode_compound): Likewise. * cli/cli-utils.h (remove_trailing_whitespace): New function. * cli/cli-utils.c (remove_trailing_whitespace): Likewise. PR c++/12273 * linespec.c (locate_first_half): Keep overload information, too. (decode_compound): Use a string to represent break characters to escape the loop. If P points to a break character, do not increment it. For C++ and Java, keep overload information and relevant keywords. If we cannot find a symbol, search the minimal symbols. PR c++/11734 * linespec.c (decode_compound): Rename SAVED_ARG to THE_REAL_SAVED_ARG. Make a copy of THE_REAL_SAVED_ARG in SAVED_ARG and strip single-quotes. Pass a valid block to lookup_symbol. (lookup_prefix_sym): Likewise. (find_method): Construct search name based on SYM_CLASS instead of SAVED_ARG. * psymtab.c (lookup_partial_symbol): Add language parameter. (lookup_symbol_aux_psymtabs): Likewise. Don't assume that the psymtab we found was the right one. Search for the desired symbol in the symtab to be certain. (psymtab_search_name): New function. (lookup_partial_symbol): Use psymtab_search_name. Add language parameter. (read_symtabs_for_function): Add language parameter and pass to lookup_partial_symbol. (find_symbol_file_from_partial): Likewise. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/ChangeLog.diff?cvsroot=src&r1=1.12823&r2=1.12824 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/linespec.c.diff?cvsroot=src&r1=1.113&r2=1.114 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/psymtab.c.diff?cvsroot=src&r1=1.24&r2=1.25 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/cli/cli-utils.h.diff?cvsroot=src&r1=1.12&r2=1.13 http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/cli/cli-utils.c.diff?cvsroot=src&r1=1.12&r2=1.13
I believe this is now fixed. This has not been committed to the 7.2 branch.