From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10335 invoked by alias); 14 Apr 2014 22:20:11 -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 10304 invoked by uid 48); 14 Apr 2014 22:20:08 -0000 From: "dblaikie at gmail dot com" To: gdb-prs@sourceware.org Subject: [Bug c++/16843] New: GDB relies on the mangled name of a subprogram to be a prefix of the enclosing class name Date: Mon, 14 Apr 2014 22:20:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: c++ X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dblaikie at gmail dot com 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 cc 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: 2014-q2/txt/msg00057.txt.bz2 https://sourceware.org/bugzilla/show_bug.cgi?id=16843 Bug ID: 16843 Summary: GDB relies on the mangled name of a subprogram to be a prefix of the enclosing class name Product: gdb Version: unknown Status: NEW Severity: normal Priority: P2 Component: c++ Assignee: unassigned at sourceware dot org Reporter: dblaikie at gmail dot com CC: dje at google dot com, echristo at gmail dot com Originally filed as a GCC bug ( http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51668 ), I believe this is a GDB issue that will manifest more in the presence of Clang. Either GDB relies on mangled names given by DW_AT_(MIPS_)linkage_name matching substrings of DW_AT_name exactly or it doesn't. If GDB does rely on this assumption, it's by way of having re-written (or reused) the specific rules GCC uses to mangle names (judging by the presence of the "demangle-style" option, perhaps this is the case). In that case minor changes in output such as GCC's improvement between 4.6 and 4.7 will cause problems for GDB users. If GDB doesn't rely on this assumption and can handle some differences between naming (for example GCC always uses "long int" even though c++filt demangles this as "long", 'x' versus (char)120, etc, etc... ) then it's just missing a case to handle the bug reported against GCC. This is also going to be a larger issue if GDB relies on exact demangling, since it hasn't been taught at all about Clang's mangling/naming differences, some of which I suspect may rely on how the source was written. I'm hoping/have some evidence to believe that it's the latter (GDB doesn't rely on exact string matches), for example, compiling the following to source files with GCC and Clang: // source1 template struct foo; foo<1> *func(); int main() { foo<1> *f = func(); } // source2 template struct foo { void mem() { } }; foo<1> *func() { static foo<1> f; f.mem(); //ensure we instantiate 'func' so we can call it in the debugger from main return &f; } In this case, "ptype f" will give a declaration of foo<1> because the difference in mangled names (foo<'\001'> versus foo<'\x01'>) but other examples ('long int' versus 'long') don't exhibit this problem. So I assume GDB has the ability to handle some differences in some cases. Consider this a bug to handle more cases (hex V octal V cast decimal) and possibly in more places (if the prefix matching for member functions is doing substring matching) -- You are receiving this mail because: You are on the CC list for the bug.