[Bug c++/12293] New: g++ 3.x outputs wrong mangled names for some "global constructors keyed to"

[Bug c++/12293] New: g++ 3.x outputs wrong mangled names for some "global constructors keyed to"

[carlo at alinoe dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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

           Summary: g++ 3.x outputs wrong mangled names for some "global
                    constructors keyed to"
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: carlo at alinoe dot com
                CC: gcc-bugs at gcc dot gnu dot org

The mangled names of some "global constructors keyed to" symbols
have wrongly an "anonymous namespace" extention appended.

Examples that I found in the distributed libstdc++ are:

# nm /usr/local/gcc-3.0.4/lib/libstdc++.so | grep GLOBAL__I_
0004dd90 t
_GLOBAL__I__ZStorSt12_Ios_IostateS__usr_src_gcc_gcc_3.0.4_libstdc___v3_src_locale_inst.cc5yFzLb

This should be

_GLOBAL__I__ZStorSt12_Ios_IostateS_

# nm /usr/local/gcc-3.1/lib/libstdc++.so | grep GLOBAL__I_
0005fd62 t _GLOBAL__I__usr_src_gcc_gcc_3.1_libstdc___v3_src_ext_inst.ccEupxgb
0005f87a t
_GLOBAL__I__ZStorSt12_Ios_IostateS__usr_src_gcc_gcc_3.1_libstdc___v3_src_locale_inst.cchLn6gb

The first one is utter nonsense, it can not be determined
what symbol that is supposed to refer to!
The second one should be

_GLOBAL__I__ZStorSt12_Ios_IostateS_

# nm /usr/local/gcc-3.1.1/lib/libstdc++.so | grep GLOBAL__I_
000600ce t
_GLOBAL__I__ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv_usr_src_gcc_gcc_3.1.1_libstdc___v3_src_ext_inst.ccKXjyhb
00060170 t
_GLOBAL__I__ZNKSt8ios_base6getlocEv_usr_src_gcc_gcc_3.1.1_libstdc___v3_src_io_inst.ccHMOmhb
0005fbf6 t
_GLOBAL__I__ZStorSt12_Ios_IostateS__usr_src_gcc_gcc_3.1.1_libstdc___v3_src_locale_inst.ccx8rrhb

These should be

_GLOBAL__I__ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv
_GLOBAL__I__ZNKSt8ios_base6getlocEv
_GLOBAL__I__ZStorSt12_Ios_IostateS_

# nm /usr/local/gcc-3.2/lib/libstdc++.so | grep GLOBAL__I_
000629ee t
_GLOBAL__I__ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv_usr_src_gcc_gcc_3.2_libstdc___v3_src_ext_inst.ccff5vhb
0006302c t
_GLOBAL__I__ZNKSt8ios_base6getlocEv_usr_src_gcc_gcc_3.2_libstdc___v3_src_io_inst.ccteZohb
00062516 t
_GLOBAL__I__ZStorSt12_Ios_IostateS__usr_src_gcc_gcc_3.2_libstdc___v3_src_locale_inst.ccD93Hhb

These should be

_GLOBAL__I__ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv
_GLOBAL__I__ZNKSt8ios_base6getlocEv
_GLOBAL__I__ZStorSt12_Ios_IostateS_

# nm /usr/local/gcc-3.2.1/lib/libstdc++.so | grep GLOBAL__I_
00047e76 t
_GLOBAL__I__ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv_usr_src_gcc_gcc_3.2.1_libstdc___v3_src_ext_inst.cc1vvuhb
00050570 t
_GLOBAL__I__ZNKSt8ios_base6getlocEv_usr_src_gcc_gcc_3.2.1_libstdc___v3_src_io_inst.ccRoMhhb
0005d772 t
_GLOBAL__I__ZStorSt12_Ios_IostateS__usr_src_gcc_gcc_3.2.1_libstdc___v3_src_locale_inst.ccdpmgib

These should be

_GLOBAL__I__ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv
_GLOBAL__I__ZNKSt8ios_base6getlocEv
_GLOBAL__I__ZStorSt12_Ios_IostateS_

# nm /usr/local/gcc-3.2.2/lib/libstdc++.so | grep GLOBAL__I_
00047eca t
_GLOBAL__I__ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv_usr_src_gcc_gcc_3.2.2_libstdc___v3_src_ext_inst.ccqKhyhb
000505b8 t
_GLOBAL__I__ZNKSt8ios_base6getlocEv_usr_src_gcc_gcc_3.2.2_libstdc___v3_src_io_inst.cc7EMmhb
0005d68e t
_GLOBAL__I__ZStorSt12_Ios_IostateS__usr_src_gcc_gcc_3.2.2_libstdc___v3_src_locale_inst.ccdJqcib

These should be

_GLOBAL__I__ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv
_GLOBAL__I__ZNKSt8ios_base6getlocEv
_GLOBAL__I__ZStorSt12_Ios_IostateS_

# nm /usr/local/gcc-3.2.3/lib/libstdc++.so | grep GLOBAL__I_
00047eca t
_GLOBAL__I__ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv_usr_src_gcc_gcc_3.2.3_libstdc___v3_src_ext_inst.ccd08xhb
00050614 t
_GLOBAL__I__ZNKSt8ios_base6getlocEv_usr_src_gcc_gcc_3.2.3_libstdc___v3_src_io_inst.ccBmEmhb
0005d6ea t
_GLOBAL__I__ZStorSt12_Ios_IostateS__usr_src_gcc_gcc_3.2.3_libstdc___v3_src_locale_inst.cc3hicib

These should be

_GLOBAL__I__ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv
_GLOBAL__I__ZNKSt8ios_base6getlocEv
_GLOBAL__I__ZStorSt12_Ios_IostateS_

# nm /usr/local/gcc-3.3/lib/libstdc++.so | grep GLOBAL__I_
0003f8cc t
_GLOBAL__I__ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv_usr_src_gcc_gcc_3.3_libstdc___v3_src_ext_inst.ccoqpshb
0006a9b8 t
_GLOBAL__I__ZNSt21__ctype_abstract_baseIcED0Ev_usr_src_gcc_gcc_3.3_libstdc___v3_src_locale_inst.cc43Qhjb
00047dd8 t
_GLOBAL__I__ZThn8_NSt14basic_iostreamIwSt11char_traitsIwEED0Ev_usr_src_gcc_gcc_3.3_libstdc___v3_src_io_inst.ccc5UEhb

These should be

_GLOBAL__I__ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv
_GLOBAL__I__ZNSt21__ctype_abstract_baseIcED0Ev
_GLOBAL__I__ZThn8_NSt14basic_iostreamIwSt11char_traitsIwEED0Ev

# nm /usr/local/gcc-3.3.1/lib/libstdc++.so | grep GLOBAL__I_
0003fa04 t
_GLOBAL__I__ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv_usr_src_gcc_gcc_3.3.1_libstdc___v3_src_ext_inst.ccJ2sTea
0006b3e0 t
_GLOBAL__I__ZNSt21__ctype_abstract_baseIcED0Ev_usr_src_gcc_gcc_3.3.1_libstdc___v3_src_locale_inst.ccJufoad
00047f10 t
_GLOBAL__I__ZThn8_NSt14basic_iostreamIwSt11char_traitsIwEED0Ev_usr_src_gcc_gcc_3.3.1_libstdc___v3_src_io_inst.ccC9CWwb

These should be

_GLOBAL__I__ZN9__gnu_cxx13stdio_filebufIwSt11char_traitsIwEE2fdEv
_GLOBAL__I__ZNSt21__ctype_abstract_baseIcED0Ev
_GLOBAL__I__ZThn8_NSt14basic_iostreamIwSt11char_traitsIwEED0Ev

# nm /usr/local/gcc-cvs-3.4/lib/libstdc++.so | grep GLOBAL__I_
0004d0e0 t
_GLOBAL__I__usr_src_gcc_gcc_cvs_3.4_libstdc___v3_src_ext_inst.cc_C82FF1AF_EFA14B60
000563c0 t
_GLOBAL__I__usr_src_gcc_gcc_cvs_3.4_libstdc___v3_src_io_inst.cc_03FB521F_FF626C4C
0007f520 t
_GLOBAL__I__usr_src_gcc_gcc_cvs_3.4_libstdc___v3_src_locale_inst.cc_2E1E1B9E_063B209F

These are three times total nonsense.

[Bug c++/12293] g++ 3.x outputs wrong mangled names for some "global constructors keyed to"

[bangerth at dealii dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From bangerth at dealii dot org  2003-09-16 20:14 -------
Carlo, you know more about this than I do, so bear with a layman: why is it wrong if 
the names of these global constructors have a disambiguation part? As far as I 
understand it, they are for internal use only anyway, so we may use any name 
we want, no? Or is there an ABI specification or similar that I'm not aware of? 
 
Thanks   
  Wolfgang

[Bug c++/12293] g++ 3.x outputs wrong mangled names for some "global constructors keyed to"

[carlo at alinoe dot com]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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



------- Additional Comments From carlo at alinoe dot com  2003-09-17 02:35 -------
Subject: Re:  g++ 3.x outputs wrong mangled names for some "global constructors keyed to"

Because "_GLOBAL__I_" is a GNU extention anyway, I can't say that
it really _is_ wrong - this is not covered by any standard as it is.

However, it makes no sense - why would you add garbage behind
those symbols?  It looks like it isn't intentional (and therefore
a bug).

Moreoever, it is very unlogical from the point of view of
demangling (my demangler barfs on it) - it would demand dirty
code hacks to make the demangler demangle this.

Also, if you look at the disambiguation part that is used
together with _GLOBAL__N_ (anonymous namespaces), then it has
a length, for example:

65_GLOBAL__N_.....................................................

where the '65' at least tells the demangler how long the garbage is.

Because the length part is missing, this cannot be looked at as an
'encoding': there would be no way to use it as 'encoding' inside a
mangled name that uses an encoding in the middle of a larger
encoding.  Perhaps all of this is never a problem, because
1) it is always a symbol that is only local, and
2) the disambiguation part is always the trailing part (so length
   doesn't matter).

but, imho - it shouldn't be there.  There is nothing to disambiguation
to begin with.

Finally, I didn't put it in the bug report, but there are several
cases of _GLOBAL__I_ symbols *without* this trailing disambiguation
part.

[Bug c++/12293] wrong mangled names for some "global constructors keyed to"

[bangerth at dealii dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


bangerth at dealii dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-09-17 13:53:50
               date|                            |
            Summary|g++ 3.x outputs wrong       |wrong mangled names for some
                   |mangled names for some      |"global constructors keyed
                   |"global constructors keyed  |to"
                   |to"                         |


------- Additional Comments From bangerth at dealii dot org  2003-09-17 13:53 -------
OK, makes sense. Thanks for the explanation!

[Bug c++/12293] wrong mangled names for some "global constructors keyed to"

[carlo at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


carlo at gcc dot gnu dot org changed:

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


------- Additional Comments From carlo at gcc dot gnu dot org  2003-09-30 20:09 -------
I looked at the source code that generates these symbols,
and apparently it IS on purpose.  I am still not convinced
that a disambiguation part is needed here because I under-
stand there is at most one _GLOBAL__I_ symbol per compilation
unit, but well - it is used, so instead I'll fix the demangler
to understand it.

The format of _GLOBAL__I_* symbols is apparently:

_GLOBAL__I_<first global symbol in compilation unit>

or if that doesn't exist

_GLOBAL__I_<first weak global symbol in compilation unit><disambiguation part>

or, if there is no weak symbol either

_GLOBAL__I_<disambiguation part>