From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12313 invoked by alias); 16 Sep 2013 22:04:13 -0000 Mailing-List: contact gdb-prs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-prs-owner@sourceware.org Received: (qmail 12289 invoked by uid 48); 16 Sep 2013 22:04:12 -0000 From: "jifl-bugzilla at jifvik dot org" To: gdb-prs@sourceware.org Subject: [Bug symtab/15962] New: break / rbreak fails to match C linkage C++ functions with user-defined types Date: Mon, 16 Sep 2013 22:04:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Version: 7.6 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: jifl-bugzilla at jifvik dot org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-q3/txt/msg00356.txt.bz2 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.