[Bug symtab/15962] New: break / rbreak fails to match C linkage C++ functions with user-defined types

["jifl-bugzilla at jifvik dot org" <sourceware-bugzilla@sourceware.org>]

http://sourceware.org/bugzilla/show_bug.cgi?id=15962

            Bug ID: 15962
           Summary: break / rbreak fails to match C linkage C++ functions
                    with user-defined types
           Product: gdb
           Version: 7.6
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: jifl-bugzilla at jifvik dot org

Created attachment 7199
  --> http://sourceware.org/bugzilla/attachment.cgi?id=7199&action=edit
Test case demonstrating rbreak failing to match

First off, I am using GDB 7.6.1.

To see the problem, compile the attached test case without optimisation. I used
arm-eabi-gcc 4.7.3, but I doubt that matters. Using rbreak to set a breakpoint
fails to match bfunc(), although it does match the equivalent afunc().

(gdb) rbreak afunc
Breakpoint 1 at 0x20040748: file foo.cxx, line 7.
void afunc(int);
(gdb) rbreak bfunc
Function "bfunc(mytype)" not defined in "/local/builds/arm/473/foo.cxx".
void bfunc(mytype);
(gdb) 

Equivalently for 'break':
(gdb) b afunc(int)
Breakpoint 5 at 0x20040748: file foo.cxx, line 7.
(gdb) b bfunc(mytype)
Function "bfunc(mytype)" not defined.
(gdb) 


Setting a breakpoint with just "break bfunc" *does* work correctly as that uses
the symbol table.

The elements needed to reproduce this are that there must be a user-defined
type in the function signature, the file must be a C++ file, but the functions
have C linkage. It appears to be a clash in GDB's expectations of a C++-defined
type, and a C linkage function that causes the problem.

This used to work in GDB 7.2 and earlier. I haven't checked 7.3, 7.4 or 7.5.

I'm not quite sure exactly where the fault lies, but in my attempts to debug
GDB I see that find_linespace_symbols() calls
"cp_canonicalize_string_no_typedefs()" to get the canonical name to look up,
and at that point the name being looked for changes from "bfunc(mytype)" to
"bfunc(int)". If I manually change GDB's state to revert it back to
bfunc(mytype) then it *does* match the location correctly.

My first guess to a fix was to add a call to
cp_canonicalize_string_no_typedefs() to symbol_natural_name() in symtab.c, but
I think that probably wants to be the name the user sees, so I guess not that.
So I think the most likely fix to my mind is to canonicalize the return from
SYMBOL_SEARCH_NAME in dictionary.c's iter_match_first_hashed() and
iter_match_next_hashed() before comparing the symbols. And probably
iter_match_next_linear().

But I'm still not sure about potential side-effects. If someone can give
guidance, I can probably work something out.

Thanks in advance!

Jifl

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