[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

[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 <***@eCosCentric.com>

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

[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

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

[jifl-bugzilla at jifvik dot org]

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

--- Comment #3 from Jonathan Larmour <jifl-bugzilla at jifvik dot org> ---
Just to update: this problem still exists in GDB 8.1.

Jifl

[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.8 |8.1