[Bug c++/16843] New: GDB relies on the mangled name of a subprogram to be a prefix of the enclosing class name

["dblaikie at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

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<char c> struct foo;
foo<1> *func();
int main() { foo<1> *f = func(); }

// source2
template<char c> 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.