public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* Name mangling issue with HP, Sun, Tru64 UNIX C++ but not GCC
@ 2006-02-01 17:45 Albert Chin
  2006-02-01 18:21 ` Andrew Pinski
  0 siblings, 1 reply; 3+ messages in thread
From: Albert Chin @ 2006-02-01 17:45 UTC (permalink / raw)
  To: gcc

We ran into a problem building KDE on HP-UX 11.23/IA with the HP C++
compiler. The compiler mangled a function name in a .cpp file though
it was declared extern "C" in the .h file. After a post to the HP C++
developers list, we were told this behavior is correct. GCC 4.0.2 does
not do this so I'd like to get your opinion.

$ cat mangle-1.cc
typedef enum {
  XSLDBG_MSG_THREAD_NOTUSED,
  XSLDBG_MSG_THREAD_INIT
} XsldbgMessageEnum;

extern "C" {
  void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
                                                     const void *data));
}

static int (*notifyXsldbgAppFuncPtr) (XsldbgMessageEnum type,
                                      const void *data) = 0;

void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
                                                   const void *data))
{
  notifyXsldbgAppFuncPtr = notifyXsldbgAppFunc;
}

$ g++ --version
g++ (GCC) 4.0.2 (TWW)
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
$ g++ -c mangle-1.cc
$ nm mangle-1.o | grep -i xsldbg
0000000000000000 b notifyXsldbgAppFuncPtr
0000000000000000 T xsldbgSetAppFunc

So, GCC isn't mangling it. Now for the HP C++ compiler:
  [HP-UX 11.23/IA]
  $ aCC -AA -c mangle-1.cc
  # nm mangle-1.o | grep -i xsldbg
  [9]      |            0|      48|FUNC |GLOB |0|   .text|_Z16xsldbgSetAppFuncPFi17XsldbgMessageEnumPKvE

Let's try some other compilers:
  [Solaris 8]
  $ CC -V
  CC: Sun C++ 5.5 Patch 113817-15 2005/10/25
  $ CC -c mangle-1.cc
  "mangle-1.cc", line 15: Warning: function void(int(*)(XsldbgMessageEnum,const void*)) overloads extern "C" void(extern "C" int(*)(XsldbgMessageEnum,const void*)) because of different language linkages.
  1 Warning(s) detected.
  $ nm mangle-1.o | grep -i xsldbg
  [4]     |        16|      36|FUNC |GLOB |0    |2 |__1cQxsldbgSetAppFunc6FpFnRXsldbgMessageEnum_pkv_i_v_
  [3]     |         0|       4|OBJT |LOCL |0    |3 |notifyXsldbgAppFuncPtr

  [IRIX 6.5]
  $ CC -version
  MIPSpro Compilers: Version 7.4.4m
  $ CC -c mangle-1.cc
  $ nm mangle-1.o | grep -i xsldbg
  [3]     |         0|      40|FUNC |GLOB |DEFAULT  |5 |xsldbgSetAppFunc
  [16]    |         0|       0|STAT |LOCL |DEFAULT |MIPS_DATA|notifyXsldbgAppFuncPtr

  [AIX 5.3]
  $ xlC -c mangle-1.cc
  $ nm mangle-1.o | grep -i xsldbg
  .xsldbgSetAppFunc    T           0
  xsldbgSetAppFunc     D          88          12
  xsldbgSetAppFunc     d          80           4

  [Tru64 UNIX 5.1]
  $ cxx -version V7.1-006 -V
  Compaq C++ V7.1-006 for Compaq Tru64 UNIX V5.1 (Rev. 732)
  Compiler Driver V7.1-006 (cxx) cxx Driver
  $ cxx -version V7.1-006 -c mangle-1.cc
  $ nm mangle-1.o | grep -i xsldbg      
  xsldbgSetAppFunc(int (*)(XsldbgMessageEnum, const void*)) | 0000000000000000 | T | 0000000000000008

So, it looks like the HP-UX/IA, Sun, and Tru64 UNIX C++ compilers
mangle but the AIX, SGI, and GNU C++ compilers do not.

Fixing mangle-1.c for HP, Sun, and Tru64 UNIX is easy (after the HP
developer told me how to do it):
  $ cat mangle-2.cc
  typedef enum {
    XSLDBG_MSG_THREAD_NOTUSED,
    XSLDBG_MSG_THREAD_INIT
  } XsldbgMessageEnum;

  typedef int (*notifyXsldbgAppFuncType) (XsldbgMessageEnum type,
                                          const void *data);

  extern "C" {
    void xsldbgSetAppFunc (notifyXsldbgAppFuncType notifyXsldbgAppFunc);
  }

  static notifyXsldbgAppFuncType notifyXsldbgAppFuncPtr = 0;

  void xsldbgSetAppFunc (notifyXsldbgAppFuncType notifyXsldbgAppFunc) {
    notifyXsldbgAppFuncPtr = notifyXsldbgAppFunc;
  }

According to the HP developer:
 >This is a subtle one that we see fairly often.  The problem is that
 >there are two functions xsldbgSetAppFunc with different types.  The
 >first (the declaration) has a parameter of type
 >
 >*notifyXsldbgAppFunc) (XsldbgMessageEnum type, const void *data)
 >
 >and that parameter has C linkage.  The second (the definition, which
 >ends up being mangled) has a parameter of type:
 >
 >*notifyXsldbgAppFunc) (XsldbgMessageEnum type, const void *data)
 >
 >but that parameter has C++ linkage.  Since this is recognized as a
 >different function because of the difference in parameter, and is not
 >itself enclosed in an extern "C" block, it is mangled.
 >
 >To get these to match, you need to define a type for the parameter
 >which has C linkage and use it in both places, or place the entire
 >definition in an extern "C" block, if that will fork for your actual
 >situation.

 >The linkage of a parameter that is a function is considered in its type.   
 >One has C linkage, the other C++ linkage.  It is subtle.

Who is right?

-- 
albert chin (china@thewrittenword.com)

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Name mangling issue with HP, Sun, Tru64 UNIX C++ but not GCC
  2006-02-01 17:45 Name mangling issue with HP, Sun, Tru64 UNIX C++ but not GCC Albert Chin
@ 2006-02-01 18:21 ` Andrew Pinski
  2006-02-20 19:35   ` Albert Chin
  0 siblings, 1 reply; 3+ messages in thread
From: Andrew Pinski @ 2006-02-01 18:21 UTC (permalink / raw)
  To: gcc

> 
> We ran into a problem building KDE on HP-UX 11.23/IA with the HP C++
> compiler. The compiler mangled a function name in a .cpp file though
> it was declared extern "C" in the .h file. After a post to the HP C++
> developers list, we were told this behavior is correct. GCC 4.0.2 does
> not do this so I'd like to get your opinion.
> 
> $ cat mangle-1.cc
> typedef enum {
>   XSLDBG_MSG_THREAD_NOTUSED,
>   XSLDBG_MSG_THREAD_INIT
> } XsldbgMessageEnum;
> 
> extern "C" {
>   void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
>                                                      const void *data));
> }
> 
> static int (*notifyXsldbgAppFuncPtr) (XsldbgMessageEnum type,
>                                       const void *data) = 0;
> 
> void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
>                                                    const void *data))
> {
>   notifyXsldbgAppFuncPtr = notifyXsldbgAppFunc;
> }

This is most likely very related to PR 2316 where GCC does not use language
as the overloaded part.  

-- Pinski

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: Name mangling issue with HP, Sun, Tru64 UNIX C++ but not GCC
  2006-02-01 18:21 ` Andrew Pinski
@ 2006-02-20 19:35   ` Albert Chin
  0 siblings, 0 replies; 3+ messages in thread
From: Albert Chin @ 2006-02-20 19:35 UTC (permalink / raw)
  To: gcc

On Wed, Feb 01, 2006 at 01:21:03PM -0500, Andrew Pinski wrote:
> > 
> > We ran into a problem building KDE on HP-UX 11.23/IA with the HP C++
> > compiler. The compiler mangled a function name in a .cpp file though
> > it was declared extern "C" in the .h file. After a post to the HP C++
> > developers list, we were told this behavior is correct. GCC 4.0.2 does
> > not do this so I'd like to get your opinion.
> > 
> > $ cat mangle-1.cc
> > typedef enum {
> >   XSLDBG_MSG_THREAD_NOTUSED,
> >   XSLDBG_MSG_THREAD_INIT
> > } XsldbgMessageEnum;
> > 
> > extern "C" {
> >   void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
> >                                                      const void *data));
> > }
> > 
> > static int (*notifyXsldbgAppFuncPtr) (XsldbgMessageEnum type,
> >                                       const void *data) = 0;
> > 
> > void xsldbgSetAppFunc (int (*notifyXsldbgAppFunc) (XsldbgMessageEnum type,
> >                                                    const void *data))
> > {
> >   notifyXsldbgAppFuncPtr = notifyXsldbgAppFunc;
> > }
> 
> This is most likely very related to PR 2316 where GCC does not use language
> as the overloaded part.  

Is there some place in the C++ standard I can look up to determine
what the correct behavior for the above code should be?

-- 
albert chin (china@thewrittenword.com)

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-02-20 19:35 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-02-01 17:45 Name mangling issue with HP, Sun, Tru64 UNIX C++ but not GCC Albert Chin
2006-02-01 18:21 ` Andrew Pinski
2006-02-20 19:35   ` Albert Chin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).