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

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

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.

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

[gbenson at redhat dot com]

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

Gary Benson <gbenson at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gbenson at redhat dot com

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

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

[gbenson at redhat dot com]

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

--- Comment #1 from Gary Benson <gbenson at redhat dot com> ---
David, I don't have a copy of Clang to hand.  Could you run nm on the object
files you have generated with GCC and Clang and paste the mangled symbol names
here please?

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

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

[dblaikie at gmail dot com]

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

--- Comment #2 from David Blaikie <dblaikie at gmail dot com> ---
(In reply to Gary Benson from comment #1)
> David, I don't have a copy of Clang to hand.  Could you run nm on the object
> files you have generated with GCC and Clang and paste the mangled symbol
> names here please?

Hmm, I'm not sure if that's relevant (I'm wondering if perhaps I did a poor job
explaining the problem - or I just don't understand it at all), but the default
output of "nm" for the two object files no matter whether they're compiled with
GCC or Clang is:

src1.cpp:
0000000000000000 T _Z4funcv
0000000000000000 W _ZN3fooILc1EE3memEv
0000000000000000 b _ZZ4funcvE1f

src2.cpp:
                 U _Z4funcv
0000000000000000 T main

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

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

[tromey at redhat dot com]

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

Tom Tromey <tromey at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at redhat dot com

--- Comment #3 from Tom Tromey <tromey at redhat dot com> ---
(In reply to David Blaikie from comment #0)

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

gdb doesn't rely on this.
Instead it does name canonicalization.

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

This is a bit curious since I was under the impression that gdb
demangled the linkage name, canonicalized it, and then used that name.
So, barring cases where "physname" must be computed, I thought gdb
wouldn't be using the name in the debuginfo.

But, no big deal, some part of my understanding must be wrong.
Probably a bug in the canonicalization code.

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

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

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

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

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
There are some differences between the canonicalizer
and the demangler, see bug #17762.  Is that what is 
meant here?

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

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

[dblaikie at gmail dot com]

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

--- Comment #6 from David Blaikie <dblaikie at gmail dot com> ---
(In reply to Tom Tromey from comment #5)
> There are some differences between the canonicalizer
> and the demangler, see bug #17762.  Is that what is 
> meant here?

Yeah, they're certainly similar bugs - I don't know enough about the GDB
implementation details to know if they're totally duplicate/identical root
cause.

One difference (that may be superficial) is that this bug is about type names,
that bug is about function names, at least partially.

But, yeah, that char literals aren't canonicalized where other types like `long
int`/`long` is the/a bug somewhere. There's probably other canonicalization
issues for interesting literals - I think I came across a few in Clang.

(lambdas are the worst - I've tried to have some discussion with the DWARF
Committee about how we should render templates instantiated with lambdas in
such a way that they can be canonicalized between compilations and between
compilers... )

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

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

[tromey at sourceware dot org]

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

--- Comment #7 from Tom Tromey <tromey at sourceware dot org> ---
I added a "maint canonicalize" command and now the problem is
reasonably clear:

(gdb) maint canonicalize void C<(char)1>::m()
No change.
(gdb) maint canonicalize void C<'\001'>::m()
canonical = void C<(char)'\001'>::m()


I think these should canonicalize to the same thing.

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

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

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at sourceware dot org   |tromey at sourceware dot org

--- Comment #8 from Tom Tromey <tromey at sourceware dot org> ---
Testing a patch.

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