[Bug c++/40831] New: g++ generated symbols for cloned function that be demangled.

[Bug c++/40831] New: g++ generated symbols for cloned function that be demangled.

[cgd at google dot com]

G++ generates symbols for cloned functions that cannot be demangled, because of
".clone.N".

compiler version:

$ inst/bin/gcc -v
Using built-in specs.
Target: x86_64-linux
Configured with: ../trunk/configure --enable-languages=c,c++,fortran
--build=x86_64-linux --host=x86_64-linux --target=x86_64-linux
--prefix=/g/users/cgd/proj/gcc-trunk/bld/../inst
Thread model: posix
gcc version 4.5.0 20090722 (experimental) (GCC) 


I'll upload an example shortly.  For that example:

[cgd@bcpl gcc-trunk]$ inst/bin/gcc x.cc -c -O3
[cgd@bcpl gcc-trunk]$ ../binutils/inst.ld/bin/nm -an x.o
                 U _Z10externfuncv
                 U __gxx_personality_v0
0000000000000000 b .bss
0000000000000000 n .comment
0000000000000000 d .data
0000000000000000 r .eh_frame
0000000000000000 n .note.GNU-stack
0000000000000000 t .text
0000000000000000 t _Z12to_be_clonediPv.clone.0
0000000000000000 a x.cc
00000000000000c0 T _Z12to_be_clonediPv
0000000000000190 T _Z3fooPv
00000000000001b0 T _Z3barPv
[cgd@bcpl gcc-trunk]$ ../binutils/inst.ld/bin/nm -anC x.o
                 U externfunc()
                 U __gxx_personality_v0
0000000000000000 b .bss
0000000000000000 n .comment
0000000000000000 d .data
0000000000000000 r .eh_frame
0000000000000000 n .note.GNU-stack
0000000000000000 t .text
0000000000000000 t _Z12to_be_clonediPv.clone.0
0000000000000000 a x.cc
00000000000000c0 T to_be_cloned(int, void*)
0000000000000190 T foo(void*)
00000000000001b0 T bar(void*)

This may cause problems for tools (e.g., profilers, analysis tools), which
think they understand how to demangle symbols according to the ABI and want to
present demangled names to users.

Use of local-name might be appropriate here, I'm not sure.

(There may also be debugger implications of this.)


-- 
           Summary: g++ generated symbols for cloned function that be
                    demangled.
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: cgd at google dot com
 GCC build triplet: x86_64-linux
  GCC host triplet: x86_64-linux
GCC target triplet: x86_64-linux


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[cgd at google dot com]

------- Comment #1 from cgd at google dot com  2009-07-22 23:29 -------
Created an attachment (id=18239)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18239&action=view)
example c++ input that shows creation of a cloned function which isn't
demangled.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2009-07-22 23:35 -------
I don't see a problem with this really since it is a local symbol and will
never be exported so the ABI never gets involved.  

a demangled name is only a nice way of displaying the name to the user rather
than anything else.  The profiles and other tools could figure out if it has
.clone.n to strip that and then add it back.  User generated symbols will never
have .clone.n in it unless asm is used.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2009-07-22 23:36 -------
Also by the way 4.4.0 and before generated just T.N which is even worse than
the current behavior.

> demangle symbols according to the ABI an

What is an ABI for a local symbol?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[cgd at google dot com]

------- Comment #4 from cgd at google dot com  2009-07-22 23:44 -------
(In reply to comment #2)
> I don't see a problem with this really since it is a local symbol and will
> never be exported so the ABI never gets involved.  
> 
> a demangled name is only a nice way of displaying the name to the user rather
> than anything else.  The profiles and other tools could figure out if it has
> .clone.n to strip that and then add it back.  User generated symbols will never
> have .clone.n in it unless asm is used.

I could buy your argument, I'm just not quite sure yet.


If this is reasonable output from the compiler, then people will need to take
action (e.g., enhance the debugger, and enhance any tools they care about).

I think output from 'nm' are a good first example case.  What do *you* (or
others) think is appropriate output from 'nm' in this example?  (IIRC binutils
uses the gcc-supplied demangler, right?)

Do you have guidance for how functions like these should be presented by other
tools, e.g., gdb?


BTW, I definitely agree that the current behavior is much more useful than
T.nnnn.  8-)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

Dmitry Gorbachev <d.g.gorbachev at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |d.g.gorbachev at gmail dot
                   |                            |com

--- Comment #5 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2011-01-05 01:07:00 UTC ---
There's also a binutils bug <http://sourceware.org/PR12337>:

> Programs objdump, nm, addr2line, c++filt, gprof, do not demangle cloned
> function names, such as _ZN1C3fooEi.isra.0. Could be C::foo.isra.0(int) or
> C::foo(int).isra.0 (?)

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[hubicka at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.01.06 14:07:31
                 CC|                            |dj at redhat dot com,
                   |                            |hubicka at gcc dot gnu.org,
                   |                            |ian at airs dot com
     Ever Confirmed|0                           |1
           Severity|normal                      |enhancement

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-01-06 14:07:31 UTC ---
We certainly can improve libiberty demangler to handle the cloning suffixes.
It would not hurt and is certainly nice thing to have. I am not terribly
familiar with demnagler implementation so I would preffer someone else to do
it.

Concerning question how  _ZN1C3fooEi.isra.0. should be demangled, I think we
already use english sentences for some functions names like "static constructor
keyed to XYZ", so probably we can go "C::foo(int) isra clone 0" or we even can
go further and expand the abbrebiated names GCC use for different types of
clones.

For most of purposes however the tools should use debug info that contains the
correct link back to original function...

Marking as enhancement request and adding our libiberty maintainers into CC.

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[ccoutant at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

Cary Coutant <ccoutant at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot       |ccoutant at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #7 from Cary Coutant <ccoutant at gcc dot gnu.org> 2011-02-23 02:00:08 UTC ---
Created attachment 23439
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23439
Patch to add demangler support for cloned function symbols

include/ChangeLog:

        PR 40831
        * demangle.h (enum demangle_component_type): Add
        DEMANGLE_COMPONENT_CLONE, DEMANGLE_COMPONENT_CONSTPROP_CLONE,
        DEMANGLE_COMPONENT_ISRA_CLONE, DEMANGLE_COMPONENT_PART_CLONE.

libiberty/ChangeLog:

        PR 40831
        * cp-demangle.c (struct clone_suffix_list): New type.
        (d_make_comp): Add new component types.
        (cplus_demangle_mangled_name): Check for clone suffixes.
        (d_parmlist): Don't error out if we see '.'.
        (clone_suffixes): New array.
        (d_clone_suffix): New function.
        (d_print_comp): Print info for clone suffixes.
        * testsuite/demangle-expected: Add new testcases.

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

--- Comment #8 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2011-02-23 07:53:45 UTC ---
Does not work for `_Z3fooi.1988' or
`_Z3fooi.part.9.165493.constprop.775.31805'.

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[ccoutant at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

--- Comment #9 from Cary Coutant <ccoutant at gcc dot gnu.org> 2011-02-23 18:30:19 UTC ---
> Does not work for `_Z3fooi.1988' or
> `_Z3fooi.part.9.165493.constprop.775.31805'.

Where does the _Z3fooi.1988 style come from?

I guess your second example is from a cloned function (due to partial inlining)
that got cloned again (due to constant propagation), but why are there two
numbers on each?

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[hubicka at ucw dot cz]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

--- Comment #10 from Jan Hubicka <hubicka at ucw dot cz> 2011-02-23 19:03:36 UTC ---
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831
> 
> --- Comment #9 from Cary Coutant <ccoutant at gcc dot gnu.org> 2011-02-23 18:30:19 UTC ---
> > Does not work for `_Z3fooi.1988' or
> > `_Z3fooi.part.9.165493.constprop.775.31805'.
> 
> Where does the _Z3fooi.1988 style come from?
We add the .1234 suffixes in LTO for local symbols (to avoid clashes in between
two static
variables of the same name).

As WHOPR progress, we might end up adding two numbered suffixes, because we
mangle at wpa time and then ship the mangled symbols to ltrans when we mangle
again.  Disabling the second mangling is trivial, but no one did it yet.  The
first mangling happens even when tere are no conflicts that is stupid, but in
case of conflicts it needs to happen.
> 
> I guess your second example is from a cloned function (due to partial inlining)
> that got cloned again (due to constant propagation), but why are there two
> numbers on each?
_Z3fooi.1988 is created from _Z3fooi by LTO mangling.

We also do precisely same mangling from function static variables, i.e.
test()
{
  static int a;
}

will get out a as a.1234

_Z3fooi becomes _Z3fooi.part.9 by partial inlining
.165493 is added at WPA time because function is static (all partial functions
are)
.constprop.775 is added because one of argument was proved to be constant by
cprop pass
.31805 comes from (completely redundant) name mangling at ltrans time. 

It is possible to change way we mangle the LTO vars, if neccesary for some good
reason.

Those numbered suffixes that do not come from function versioning (i.e. don't
have .part or .constprop) are redundant, so I guess they might be just silently
dropped?

Honza

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[ccoutant at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

Cary Coutant <ccoutant at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #23439|0                           |1
        is obsolete|                            |

--- Comment #11 from Cary Coutant <ccoutant at gcc dot gnu.org> 2011-08-20 00:54:56 UTC ---
Created attachment 25060
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25060
Updated patch to demangle cloned function symbols

This patch generalizes the clone suffix recognition, so it accepts a series of
suffixes of the form [.clonetype][.nnn]....

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[ccoutant at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

--- Comment #12 from Cary Coutant <ccoutant at gcc dot gnu.org> 2011-09-23 21:39:13 UTC ---
Author: ccoutant
Date: Fri Sep 23 21:39:10 2011
New Revision: 179132

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179132
Log:
include/ChangeLog:

    PR 40831
    * demangle.h (enum demangle_component_type): Add
    DEMANGLE_COMPONENT_CLONE.

libiberty/ChangeLog:

    PR 40831
    * cp-demangle.c (d_make_comp): Add new component type.
    (cplus_demangle_mangled_name): Check for clone suffixes.
    (d_parmlist): Don't error out if we see '.'.
    (d_clone_suffix): New function.
    (d_print_comp): Print info for clone suffixes.
    * testsuite/demangle-expected: Add new testcases.

Modified:
    trunk/include/ChangeLog
    trunk/include/demangle.h
    trunk/libiberty/ChangeLog
    trunk/libiberty/cp-demangle.c
    trunk/libiberty/testsuite/demangle-expected

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[d.g.gorbachev at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

--- Comment #13 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2011-09-24 10:39:28 UTC ---
Thanks!

It would be nice to fix it in binutils and in gdb as well.

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[ccoutant at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

--- Comment #14 from Cary Coutant <ccoutant at gcc dot gnu.org> 2011-09-26 18:29:52 UTC ---
Author: ccoutant
Date: Mon Sep 26 18:29:46 2011
New Revision: 179209

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179209
Log:
include/ChangeLog:

    PR 40831
    * demangle.h (enum demangle_component_type): Add
    DEMANGLE_COMPONENT_CLONE.

libiberty/ChangeLog:

    PR 40831
    * cp-demangle.c (d_make_comp): Add new component type.
    (cplus_demangle_mangled_name): Check for clone suffixes.
    (d_parmlist): Don't error out if we see '.'.
    (d_clone_suffix): New function.
    (d_print_comp): Print info for clone suffixes.
    * testsuite/demangle-expected: Add new testcases.


Modified:
    branches/gcc-4_6-branch/   (props changed)
    branches/gcc-4_6-branch/include/ChangeLog
    branches/gcc-4_6-branch/include/demangle.h
    branches/gcc-4_6-branch/libiberty/ChangeLog
    branches/gcc-4_6-branch/libiberty/cp-demangle.c
    branches/gcc-4_6-branch/libiberty/testsuite/demangle-expected

Propchange: branches/gcc-4_6-branch/
            ('svn:mergeinfo' added)

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[ccoutant at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

Cary Coutant <ccoutant at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #15 from Cary Coutant <ccoutant at gcc dot gnu.org> 2011-09-26 18:33:38 UTC ---
Fixed on trunk and in gcc-4_6-branch.

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andi-gcc at firstfloor dot
                   |                            |org

--- Comment #16 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-10-19 00:00:47 UTC ---
*** Bug 50783 has been marked as a duplicate of this bug. ***

[Bug c++/40831] g++ generated symbols for cloned function that be demangled.

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40831

--- Comment #17 from Andrew Pinski <pinskia at gcc dot gnu.org> 2011-10-19 00:01:54 UTC ---
(In reply to comment #13)
> It would be nice to fix it in binutils and in gdb as well.

libiberty should be merged automatically ...