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

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

[jifl-bugzilla at jifvik dot 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.

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

[jifl-bugzilla at jifvik dot org]

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

--- Comment #1 from Jonathan Larmour <jifl-bugzilla at jifvik dot org> ---
Created attachment 8099
  --> https://sourceware.org/bugzilla/attachment.cgi?id=8099&action=edit
Candidate patch to try with and without canonicalization

Hi,

I've come back to this issue as it is still present in 7.8.2. The suggested fix
I proposed was not right - cp_canonicalize_string_no_typedefs() will eventually
call lookup_symbol() (via replace_typedefs() or inspect_type()) which can cause
infinite recursion.

Therefore I am attaching a possible more straightforward fix which is to adjust
find_linespec_symbols() so that it first tries to find a function symbol for
the passed-in name, and only then repeats the search with a canonicalized
version of the name.

It certainly fixes the reported issue. So can someone have a look at it?
Thanks.

I do have an FSF assignment.

Jifl

2014-02-03  Jonathan Larmour  <jifl@eCosCentric.com>

    PR symtab/15962
    * linespec.c (find_linespec_symbols): Attempt to find function symbol
    both without and with C++ canonicalization.

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

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

[jifl-bugzilla at jifvik dot org]

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

Jonathan Larmour <jifl-bugzilla at jifvik dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|7.6                         |7.8

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

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

[jifl-bugzilla at jifvik dot org]

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

--- Comment #2 from Jonathan Larmour <jifl-bugzilla at jifvik dot org> ---
Note the year in the ChangeLog is wrong... should be 2015.

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

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

[ssbssa at sourceware dot org]

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

Hannes Domani <ssbssa at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ssbssa at sourceware dot org

--- Comment #4 from Hannes Domani <ssbssa at sourceware dot org> ---
The patch should be sent to the gdb-patches mailing list, that's where the
reviews are done.

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