gcc symbol names

gcc symbol names

[Al Niessner]

I built the egcs 1.1.2 compiler and am now having symbol name problems.
I have some old libraries that use a different naming scheme and I would
ike to know how to make the new gcc match the old gcc names.  The
difference is quite simple.  Using nm:

old name: _$_blahblahblah
new name: _._blahblahblah

How do I get the gcc I compiled to use '$' instead of '.'?

Any and all help is appreciated.


Al Niessner

Re: gcc symbol names

[Martin v. Loewis]

> I built the egcs 1.1.2 compiler and am now having symbol name problems.
> I have some old libraries that use a different naming scheme and I would
> ike to know how to make the new gcc match the old gcc names.  The
> difference is quite simple.  Using nm:
> 
> old name: _$_blahblahblah
> new name: _._blahblahblah
> 
> How do I get the gcc I compiled to use '$' instead of '.'?
> 
> Any and all help is appreciated.

You'll have to give us some more details that that. What target system
are you using? What is the exact spelling of the symbol? I very much
doubt that it is '_._blahblahblah', because it looks like a C++
destructor name, but that it would have to be '_._12blahblahblah'.
There might be a very good reason for the change in the mangling; or
it might be configuration problem.

Regards,
Martin

Re: gcc symbol names

[Al Niessner]

Target is the powerpc-wrs-vxworks.

Original names were generated using the VxWorks cross compiler (Tornado II)
on the Sun Solaris platform. The new names are being generated using egcs
1.1.2 cross compiler built for VxWorks on the Linux platform.

On Solaris platform:
> gcc --version
    cygnus-2.7.2-960126 egcs-971225 tornado 2.0

On Linux platform:
> gcc --version
    egcs-2.91.66

There are literally hundreds of these names that could be substituted for
'blahblahblah', I was just trying to reduce the scope, but here are a few
samples if you want real names (they were obtained by doing a diff on the nm
output from the .a files generated by compiling then using ar -- < is Linux
and > is Solaris):

< _._10tRTCObject
< _._11tBaseObject
< _._15TAO_ServantBase
< _._23TAO_RefCountServantBase
< _._23tDmc1308ControllerBoard
< _._5tPing
< _._Q211POA_RTCCore9RTCObject
< _._Q214POA_PingModule10PingObject
< _._Q215POA_RTCHardware5Board
< _._Q217POA_Dmc1308Module17Dmc1308Controller
---
> _$_10tRTCObject
> _$_11tBaseObject
> _$_15TAO_ServantBase
> _$_23TAO_RefCountServantBase
> _$_23tDmc1308ControllerBoard
> _$_5tPing
> _$_Q211POA_RTCCore9RTCObject
> _$_Q214POA_PingModule10PingObject
> _$_Q215POA_RTCHardware5Board
> _$_Q217POA_Dmc1308Module17Dmc1308Controller

and some more

1750,1762c384,396
< _vt.13CORBA_MARSHAL
< _vt.13CORBA_UNKNOWN
< _vt.16TAO_Object_Field
< _vt.26TAO_GIOP_Twoway_Invocation
< _vt.Q210PingModule10PingObject
< _vt.Q210PingModule10PingObject.12CORBA_Object
< _vt.Q211RTCHardware5Board
< _vt.Q211RTCHardware5Board.12CORBA_Object
< _vt.Q213Dmc1308Module17Dmc1308Controller
< _vt.Q213Dmc1308Module17Dmc1308Controller.12CORBA_Object
< _vt.Q27RTCCore9RTCObject
< _vt.Q27RTCCore9RTCObject.12CORBA_Object
<
_vt.t18TAO_Object_Field_T2ZQ213Dmc1308Module17Dmc1308ControllerZQ213Dmc1308Module21Dmc1308Controller_var

---
> _vt$13CORBA_MARSHAL
> _vt$13CORBA_UNKNOWN
> _vt$16TAO_Object_Field
> _vt$26TAO_GIOP_Twoway_Invocation
> _vt$Q210PingModule10PingObject
> _vt$Q210PingModule10PingObject$12CORBA_Object
> _vt$Q211RTCHardware5Board
> _vt$Q211RTCHardware5Board$12CORBA_Object
> _vt$Q213Dmc1308Module17Dmc1308Controller
> _vt$Q213Dmc1308Module17Dmc1308Controller$12CORBA_Object
> _vt$Q27RTCCore9RTCObject
> _vt$Q27RTCCore9RTCObject$12CORBA_Object
>
_vt$t18TAO_Object_Field_T2ZQ213Dmc1308Module17Dmc1308ControllerZQ213Dmc1308Module21Dmc1308Controller_var




It really does reduce to a '.' for '$' substitution.

All and any help is appreciated.

Al Niessner

"Martin v. Loewis" wrote:

> > I built the egcs 1.1.2 compiler and am now having symbol name problems.
> > I have some old libraries that use a different naming scheme and I would
> > ike to know how to make the new gcc match the old gcc names.  The
> > difference is quite simple.  Using nm:
> >
> > old name: _$_blahblahblah
> > new name: _._blahblahblah
> >
> > How do I get the gcc I compiled to use '$' instead of '.'?
> >
> > Any and all help is appreciated.
>
> You'll have to give us some more details that that. What target system
> are you using? What is the exact spelling of the symbol? I very much
> doubt that it is '_._blahblahblah', because it looks like a C++
> destructor name, but that it would have to be '_._12blahblahblah'.
> There might be a very good reason for the change in the mangling; or
> it might be configuration problem.
>
> Regards,
> Martin

Re: gcc symbol names

[Martin v. Loewis]

> Target is the powerpc-wrs-vxworks.

Ok.

> It really does reduce to a '.' for '$' substitution.

The name of constructor symbols is determined in gcc/cp/tree.h,
depending on the value of NO_DOLLAR_IN_LABEL:

#ifndef NO_DOLLAR_IN_LABEL
#define DESTRUCTOR_DECL_PREFIX "_$_"
...

This is defined on a per-target basis, in your case in
gcc/config/powerpc/rs6000.h. AFAICT, it was that way all the way back
to gcc 2.7.2., so it is really surprising that your original WRS
compiler did not have this define. Since you have the sources to the
original compiler, you may want to check why NO_DOLLAR_IN_LABEL was
not defined in your 2.7.2 sparc port of gcc, and apply this patch
appropriately to 2.95 (or whatever you want to use). Please note that
you'll have to recompile gcc to have this change active.

Please note that the C++ ABI has changed *significantly* since gcc
2.7.2, so there is little chance that you could possibly link C++
libraries compiled with 2.7.2 link with libraries compiled by egcs 1.1
or gcc 2.95.

Hope this helps,
Martin

Re: gcc symbol names

[Al Niessner]

I modified the gcc/config/rs6000/vxppc.h to #undef NO_DOLLAR_IN_LABEL and
#define NO_DOT_IN_LABEL and it got rid of 90 some percent of the
difference.  There are a few left though (text below).   The second
column of nm (first column in the text below) the case of the letter is
different (neither the man nor info tell me what it is supposed to mean)
or just different letters.  The two at the end of the list are completely
different names.

Any suggestions on how to resolve these last few issues?

Any and all help is appreciated.  And thanks to Martin for helping me get
this far.


Al Niessner


561,562c194,195
< t
_GLOBAL_$D$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi

< t
_GLOBAL_$I$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi

---
> T
_GLOBAL_$D$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi

> T
_GLOBAL_$I$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi

564c197
< g
_TAO_collocation_POA_Dmc1308Module_Dmc1308Controller_Stub_Factory_Initializer_Scarecrow

---
> b
_TAO_collocation_POA_Dmc1308Module_Dmc1308Controller_Stub_Factory_Initializer_Scarecrow

639c272
< r asso_values.8464
---
> r asso_values.8768
661,662c294,295
< g tao_Dmc1308Module_Dmc1308Controller_optable
< r wordlist.8467
---
> b tao_Dmc1308Module_Dmc1308Controller_optable
> r wordlist.8771


and

1683c317
< G _13Dmc1308Module$_tc_Dmc1308Controller
---
> D _13Dmc1308Module$_tc_Dmc1308Controller
1686,1688c320,322
< t
_GLOBAL_$D$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment

< t
_GLOBAL_$I$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment

< G
_TAO_collocation_Dmc1308Module_Dmc1308Controller_Stub_Factory_function_pointer

---
> T
_GLOBAL_$D$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment

> T
_GLOBAL_$I$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment

> D
_TAO_collocation_Dmc1308Module_Dmc1308Controller_Stub_Factory_function_pointer

1698c332
< U
__26TAO_Synch_Reply_DispatcherP12TAO_ORB_CoreRQ23IOP18ServiceContextList
---
> U __26TAO_Synch_Reply_DispatcherP12TAO_ORB_Core
1765d398
< U equ_common__C14CORBA_TypeCodeP14CORBA_TypeCodeUcR17CORBA_Environment
1775a409
> U private_equal__C14CORBA_TypeCodeP14CORBA_TypeCodeR17CORBA_Environment






"Martin v. Loewis" wrote:

> > Target is the powerpc-wrs-vxworks.
>
> Ok.
>
> > It really does reduce to a '.' for '$' substitution.
>
> The name of constructor symbols is determined in gcc/cp/tree.h,
> depending on the value of NO_DOLLAR_IN_LABEL:
>
> #ifndef NO_DOLLAR_IN_LABEL
> #define DESTRUCTOR_DECL_PREFIX "_$_"
> ...
>
> This is defined on a per-target basis, in your case in
> gcc/config/powerpc/rs6000.h. AFAICT, it was that way all the way back
> to gcc 2.7.2., so it is really surprising that your original WRS
> compiler did not have this define. Since you have the sources to the
> original compiler, you may want to check why NO_DOLLAR_IN_LABEL was
> not defined in your 2.7.2 sparc port of gcc, and apply this patch
> appropriately to 2.95 (or whatever you want to use). Please note that
> you'll have to recompile gcc to have this change active.
>
> Please note that the C++ ABI has changed *significantly* since gcc
> 2.7.2, so there is little chance that you could possibly link C++
> libraries compiled with 2.7.2 link with libraries compiled by egcs 1.1
> or gcc 2.95.
>
> Hope this helps,
> Martin

Re: gcc symbol names

[Martin v. Loewis]

> The second column of nm (first column in the text below) the case of
> the letter is different (neither the man nor info tell me what it is
> supposed to mean) or just different letters.

You didn't really look, did you? In by binutils info page, on
(binutils)nm

    `T'
          The symbol is in the text (code) section.

                                                         If lowercase,
     the symbol is local; if uppercase, the symbol is global (external).

So the symbol is global in one case, and local in the other. That
should not be a problem, provided the linker magic for global object
construction continues to work. Since it should be an ELF target,
making the symbols local is the right thing to do.

The difference in 'g' vs 'b' is between

    `G'
          The symbol is in an initialized data section for small
          objects.  Some object file formats permit more efficient
          access to small data objects, such as a global int variable
          as opposed to a large global array.
    `B'
          The symbol is in the uninitialized data section (known as
          BSS).

so that should not matter, either. Also asso_values.8464 is a
synthetic name indicating generated for a local variable; the
numbering may have changed for some reason, but it should not be
relevant (unless the function is inline).

> Any suggestions on how to resolve these last few issues?

Why do you need to resolve them?

Anyway, coming back to my earlier point: You really should recompile
all those libraries, as nobody will give you a guarantee that they
continue to work even if you manage to link them.

Martin

Re: gcc symbol names

[Martin v. Loewis]

> The second column of nm (first column in the text below) the case of
> the letter is different (neither the man nor info tell me what it is
> supposed to mean) or just different letters.

You didn't really look, did you? In by binutils info page, on
(binutils)nm

    `T'
          The symbol is in the text (code) section.

                                                         If lowercase,
     the symbol is local; if uppercase, the symbol is global (external).

So the symbol is global in one case, and local in the other. That
should not be a problem, provided the linker magic for global object
construction continues to work. Since it should be an ELF target,
making the symbols local is the right thing to do.

The difference in 'g' vs 'b' is between

    `G'
          The symbol is in an initialized data section for small
          objects.  Some object file formats permit more efficient
          access to small data objects, such as a global int variable
          as opposed to a large global array.
    `B'
          The symbol is in the uninitialized data section (known as
          BSS).

so that should not matter, either. Also asso_values.8464 is a
synthetic name indicating generated for a local variable; the
numbering may have changed for some reason, but it should not be
relevant (unless the function is inline).

> Any suggestions on how to resolve these last few issues?

Why do you need to resolve them?

Anyway, coming back to my earlier point: You really should recompile
all those libraries, as nobody will give you a guarantee that they
continue to work even if you manage to link them.

Martin

Re: gcc symbol names

[Al Niessner]

I modified the gcc/config/rs6000/vxppc.h to #undef NO_DOLLAR_IN_LABEL and
#define NO_DOT_IN_LABEL and it got rid of 90 some percent of the
difference.  There are a few left though (text below).   The second
column of nm (first column in the text below) the case of the letter is
different (neither the man nor info tell me what it is supposed to mean)
or just different letters.  The two at the end of the list are completely
different names.

Any suggestions on how to resolve these last few issues?

Any and all help is appreciated.  And thanks to Martin for helping me get
this far.


Al Niessner


561,562c194,195
< t
_GLOBAL_$D$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi

< t
_GLOBAL_$I$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi

---
> T
_GLOBAL_$D$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi

> T
_GLOBAL_$I$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi

564c197
< g
_TAO_collocation_POA_Dmc1308Module_Dmc1308Controller_Stub_Factory_Initializer_Scarecrow

---
> b
_TAO_collocation_POA_Dmc1308Module_Dmc1308Controller_Stub_Factory_Initializer_Scarecrow

639c272
< r asso_values.8464
---
> r asso_values.8768
661,662c294,295
< g tao_Dmc1308Module_Dmc1308Controller_optable
< r wordlist.8467
---
> b tao_Dmc1308Module_Dmc1308Controller_optable
> r wordlist.8771


and

1683c317
< G _13Dmc1308Module$_tc_Dmc1308Controller
---
> D _13Dmc1308Module$_tc_Dmc1308Controller
1686,1688c320,322
< t
_GLOBAL_$D$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment

< t
_GLOBAL_$I$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment

< G
_TAO_collocation_Dmc1308Module_Dmc1308Controller_Stub_Factory_function_pointer

---
> T
_GLOBAL_$D$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment

> T
_GLOBAL_$I$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment

> D
_TAO_collocation_Dmc1308Module_Dmc1308Controller_Stub_Factory_function_pointer

1698c332
< U
__26TAO_Synch_Reply_DispatcherP12TAO_ORB_CoreRQ23IOP18ServiceContextList
---
> U __26TAO_Synch_Reply_DispatcherP12TAO_ORB_Core
1765d398
< U equ_common__C14CORBA_TypeCodeP14CORBA_TypeCodeUcR17CORBA_Environment
1775a409
> U private_equal__C14CORBA_TypeCodeP14CORBA_TypeCodeR17CORBA_Environment






"Martin v. Loewis" wrote:

> > Target is the powerpc-wrs-vxworks.
>
> Ok.
>
> > It really does reduce to a '.' for '$' substitution.
>
> The name of constructor symbols is determined in gcc/cp/tree.h,
> depending on the value of NO_DOLLAR_IN_LABEL:
>
> #ifndef NO_DOLLAR_IN_LABEL
> #define DESTRUCTOR_DECL_PREFIX "_$_"
> ...
>
> This is defined on a per-target basis, in your case in
> gcc/config/powerpc/rs6000.h. AFAICT, it was that way all the way back
> to gcc 2.7.2., so it is really surprising that your original WRS
> compiler did not have this define. Since you have the sources to the
> original compiler, you may want to check why NO_DOLLAR_IN_LABEL was
> not defined in your 2.7.2 sparc port of gcc, and apply this patch
> appropriately to 2.95 (or whatever you want to use). Please note that
> you'll have to recompile gcc to have this change active.
>
> Please note that the C++ ABI has changed *significantly* since gcc
> 2.7.2, so there is little chance that you could possibly link C++
> libraries compiled with 2.7.2 link with libraries compiled by egcs 1.1
> or gcc 2.95.
>
> Hope this helps,
> Martin

Re: gcc symbol names

[Martin v. Loewis]

> Target is the powerpc-wrs-vxworks.

Ok.

> It really does reduce to a '.' for '$' substitution.

The name of constructor symbols is determined in gcc/cp/tree.h,
depending on the value of NO_DOLLAR_IN_LABEL:

#ifndef NO_DOLLAR_IN_LABEL
#define DESTRUCTOR_DECL_PREFIX "_$_"
...

This is defined on a per-target basis, in your case in
gcc/config/powerpc/rs6000.h. AFAICT, it was that way all the way back
to gcc 2.7.2., so it is really surprising that your original WRS
compiler did not have this define. Since you have the sources to the
original compiler, you may want to check why NO_DOLLAR_IN_LABEL was
not defined in your 2.7.2 sparc port of gcc, and apply this patch
appropriately to 2.95 (or whatever you want to use). Please note that
you'll have to recompile gcc to have this change active.

Please note that the C++ ABI has changed *significantly* since gcc
2.7.2, so there is little chance that you could possibly link C++
libraries compiled with 2.7.2 link with libraries compiled by egcs 1.1
or gcc 2.95.

Hope this helps,
Martin

Re: gcc symbol names

[Al Niessner]

Target is the powerpc-wrs-vxworks.

Original names were generated using the VxWorks cross compiler (Tornado II)
on the Sun Solaris platform. The new names are being generated using egcs
1.1.2 cross compiler built for VxWorks on the Linux platform.

On Solaris platform:
> gcc --version
    cygnus-2.7.2-960126 egcs-971225 tornado 2.0

On Linux platform:
> gcc --version
    egcs-2.91.66

There are literally hundreds of these names that could be substituted for
'blahblahblah', I was just trying to reduce the scope, but here are a few
samples if you want real names (they were obtained by doing a diff on the nm
output from the .a files generated by compiling then using ar -- < is Linux
and > is Solaris):

< _._10tRTCObject
< _._11tBaseObject
< _._15TAO_ServantBase
< _._23TAO_RefCountServantBase
< _._23tDmc1308ControllerBoard
< _._5tPing
< _._Q211POA_RTCCore9RTCObject
< _._Q214POA_PingModule10PingObject
< _._Q215POA_RTCHardware5Board
< _._Q217POA_Dmc1308Module17Dmc1308Controller
---
> _$_10tRTCObject
> _$_11tBaseObject
> _$_15TAO_ServantBase
> _$_23TAO_RefCountServantBase
> _$_23tDmc1308ControllerBoard
> _$_5tPing
> _$_Q211POA_RTCCore9RTCObject
> _$_Q214POA_PingModule10PingObject
> _$_Q215POA_RTCHardware5Board
> _$_Q217POA_Dmc1308Module17Dmc1308Controller

and some more

1750,1762c384,396
< _vt.13CORBA_MARSHAL
< _vt.13CORBA_UNKNOWN
< _vt.16TAO_Object_Field
< _vt.26TAO_GIOP_Twoway_Invocation
< _vt.Q210PingModule10PingObject
< _vt.Q210PingModule10PingObject.12CORBA_Object
< _vt.Q211RTCHardware5Board
< _vt.Q211RTCHardware5Board.12CORBA_Object
< _vt.Q213Dmc1308Module17Dmc1308Controller
< _vt.Q213Dmc1308Module17Dmc1308Controller.12CORBA_Object
< _vt.Q27RTCCore9RTCObject
< _vt.Q27RTCCore9RTCObject.12CORBA_Object
<
_vt.t18TAO_Object_Field_T2ZQ213Dmc1308Module17Dmc1308ControllerZQ213Dmc1308Module21Dmc1308Controller_var

---
> _vt$13CORBA_MARSHAL
> _vt$13CORBA_UNKNOWN
> _vt$16TAO_Object_Field
> _vt$26TAO_GIOP_Twoway_Invocation
> _vt$Q210PingModule10PingObject
> _vt$Q210PingModule10PingObject$12CORBA_Object
> _vt$Q211RTCHardware5Board
> _vt$Q211RTCHardware5Board$12CORBA_Object
> _vt$Q213Dmc1308Module17Dmc1308Controller
> _vt$Q213Dmc1308Module17Dmc1308Controller$12CORBA_Object
> _vt$Q27RTCCore9RTCObject
> _vt$Q27RTCCore9RTCObject$12CORBA_Object
>
_vt$t18TAO_Object_Field_T2ZQ213Dmc1308Module17Dmc1308ControllerZQ213Dmc1308Module21Dmc1308Controller_var




It really does reduce to a '.' for '$' substitution.

All and any help is appreciated.

Al Niessner

"Martin v. Loewis" wrote:

> > I built the egcs 1.1.2 compiler and am now having symbol name problems.
> > I have some old libraries that use a different naming scheme and I would
> > ike to know how to make the new gcc match the old gcc names.  The
> > difference is quite simple.  Using nm:
> >
> > old name: _$_blahblahblah
> > new name: _._blahblahblah
> >
> > How do I get the gcc I compiled to use '$' instead of '.'?
> >
> > Any and all help is appreciated.
>
> You'll have to give us some more details that that. What target system
> are you using? What is the exact spelling of the symbol? I very much
> doubt that it is '_._blahblahblah', because it looks like a C++
> destructor name, but that it would have to be '_._12blahblahblah'.
> There might be a very good reason for the change in the mangling; or
> it might be configuration problem.
>
> Regards,
> Martin

Re: gcc symbol names

[Martin v. Loewis]

> I built the egcs 1.1.2 compiler and am now having symbol name problems.
> I have some old libraries that use a different naming scheme and I would
> ike to know how to make the new gcc match the old gcc names.  The
> difference is quite simple.  Using nm:
> 
> old name: _$_blahblahblah
> new name: _._blahblahblah
> 
> How do I get the gcc I compiled to use '$' instead of '.'?
> 
> Any and all help is appreciated.

You'll have to give us some more details that that. What target system
are you using? What is the exact spelling of the symbol? I very much
doubt that it is '_._blahblahblah', because it looks like a C++
destructor name, but that it would have to be '_._12blahblahblah'.
There might be a very good reason for the change in the mangling; or
it might be configuration problem.

Regards,
Martin

gcc symbol names

[Al Niessner]

I built the egcs 1.1.2 compiler and am now having symbol name problems.
I have some old libraries that use a different naming scheme and I would
ike to know how to make the new gcc match the old gcc names.  The
difference is quite simple.  Using nm:

old name: _$_blahblahblah
new name: _._blahblahblah

How do I get the gcc I compiled to use '$' instead of '.'?

Any and all help is appreciated.


Al Niessner

Re: gcc symbol names

[Al Niessner]

So, how do I make the symbols 'T' instead of 't'?

The long story:

I have recompiled the ACE/TAO libraries with the cross compiler and they
have missing symbol problems too.  As I looked deeper into it I found
something interesting: The 't' does matter. Turns out all of the missing
symbols are those marked with 't' instead of 'T' like in the old
compiler.

I compiled the code using the Solaris platform (g++ 2.7.2) targetted for
VxWorks and everything works fine. I then reran "munch" which goes
through the libx.a file and extracts the globals and puts them in a C
accessable ctor/dtor file for compiling with a c compiler -- I am told
this is a need of VxWorks. The output looks like:

/* ctors and dtors arrays -- to be used by runtime system */
/*   to call static constructors and destructors          */
/*                                                        */
/* NOTE: Use a C compiler to compile this file. If you    */
/*       are using GNU C++, be sure to use compile this   */
/*       file using a GNU compiler with the               */
/*       -fdollars-in-identifiers flag.                   */


void
_GLOBAL_$I$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi();

void
_GLOBAL_$I$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment();

extern void (*_ctors[])();
void (*_ctors[])() =
    {

_GLOBAL_$I$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi,


_GLOBAL_$I$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment,

    0
    };

void
_GLOBAL_$D$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment();

void
_GLOBAL_$D$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi();

extern void (*_dtors[])();
void (*_dtors[])() =
    {

_GLOBAL_$D$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment,


_GLOBAL_$D$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi,

    0
    };

I then removed the libx.a file, all of the .o files and recompiled with
linux platform (g++ egcs 1.1.2) targetted for VxWorks. The ctor/dtor
file looks the same as the one above. It even compiles just fine. I did
an nm on the Solaris compiled ctor.o and the Linux ctor.o and they are
identical (the __FV on the symbols in previous posts was because I was
using g++ instead of gcc).

The problem comes at ld time. When the .so is build the linker magic
fails and on the Linux platform the symbols remain undefined. I then
deleted all of the generated files and recompiled with the Solaris
platform. I then used the Linux platform to ar, munch, and ld. The
resultant .so works flawlessly.

So, how do I make the symbols 'T' instead of 't'?

I read through ld man page and did not see a switch that would help me
to override the local/global status -- probably a good thing -- but I
think it is a problem with my build of gcc.

Any and all is appreciated.

And many thanks to Martin for all of his help.


Al Niessner


Oh, and Martin, I did look at the info page, but I did not read it. I
scanned the man page looking for what I wanted and did not see it amidst
the switches. I then tried the info page and when I saw all of those
letters I incorrectly thought they were switches and ignored them. Well,
needless to say, I have read them now.  Hopefully I will not do that
again because it is rather foolish.


Martin wrote:

>> The second column of nm (first column in the text below) the case of
>> the letter is different (neither the man nor info tell me what it is
>> supposed to mean) or just different letters.

> You didn't really look, did you? In by binutils info page, on
> (binutils)nm
>
>    `T'
>          The symbol is in the text (code) section.
>
>                                                         If lowercase,
>      the symbol is local; if uppercase, the symbol is global
(external).
>
> So the symbol is global in one case, and local in the other. That
> should not be a problem, provided the linker magic for global object
> construction continues to work. Since it should be an ELF target,
> making the symbols local is the right thing to do.
>
> The difference in 'g' vs 'b' is between
>
>     `G'
>           The symbol is in an initialized data section for small
>           objects.  Some object file formats permit more efficient
>           access to small data objects, such as a global int variable
>           as opposed to a large global array.
>     `B'
>           The symbol is in the uninitialized data section (known as
>           BSS).
>
> so that should not matter, either. Also asso_values.8464 is a
> synthetic name indicating generated for a local variable; the
> numbering may have changed for some reason, but it should not be
> relevant (unless the function is inline).
>
>>  Any suggestions on how to resolve these last few issues?
>
> Why do you need to resolve them?
>
> Anyway, coming back to my earlier point: You really should recompile
> all those libraries, as nobody will give you a guarantee that they
> continue to work even if you manage to link them.
>
> Martin

Re: gcc symbol names

[Martin v. Loewis]

> So, how do I make the symbols 'T' instead of 't'?

For the _GLOBAL_ symbols, the compiler decides whether to make them
static or not in gcc/cp/decl2.c:

#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
  /* It can be a static function as long as collect2 does not have
     to scan the object file to find its ctor/dtor routine.  */
  TREE_PUBLIC (current_function_decl) = 0;
#endif

Since they apparently got static, I conclude that
ASM_OUTPUT_CONSTRUCTOR is defined for your platform. It would be
really good if you had provided assembler output for a simple example
like

struct A{A();};
A a;

which would show what exactly the generated assembler code look
like. You can ask gcc to generate assembler code with the -S option.

On my platform (i586-pc-linux-gnu) it generates a fragment 

_GLOBAL_.I.a:
  ... here is the initialization of a
.section        .ctors,"aw"
  .long    _GLOBAL_.I.a

The section statement is the result of my target defining
ASM_OUTPUT_CONSTRUCTOR. On Linux, all constructor functions go into a
section .ctors. All those sections are combined by the linker to a
single section, which is at run-time processed from crtbegin.o, as
part of the .init processing. .init is an ELF section which is
automatically executed by the operating system before executing the
program entry.

> I compiled the code using the Solaris platform (g++ 2.7.2) targetted for
> VxWorks and everything works fine. I then reran "munch" which goes
> through the libx.a file and extracts the globals and puts them in a C
> accessable ctor/dtor file for compiling with a c compiler -- I am told
> this is a need of VxWorks.

Are you sure you really *need* to run "munch"? This is a historical
alternative for executing constructors, and it indeed needs the
symbols exported. Of course, if you have a real constructor section,
then the system could (and should) collect the ctors from the .ctors
section, not because their names start with _GLOBAL_.

If your target really does not support a true ctors section, then it
appears that it was incorrect to define ASM_OUTPUT_CONSTRUCTOR for
it. You need to locate the place where this is defined, and correct it
accordingly.

If you cannot find that place, you can also remove the line from
cp/decl.c as a work-around.

Regards,
Martin

Re: gcc symbol names

[Al Niessner]

I compiled the struct A sample and sure enough it was using the ctors
section. So I undefined ASM_OUTPUT_CONSTRUCTOR and it all works fine now.
Thank you very much.

I asked around about VxWorks handling the ctors section and the prevailing
thought was no it won't. It, the OS itself, really only understands C and the
munch is to merge the C to C++. For instance, when a library (.so) is loaded
in VxWorks, any of the methods are accessible through a direct call at the
command line and main() is not allowed. The loader in VxWorks is the one, I
believe, that still has no clue about ctor sections. So I have to stick with
munch.

Thanks very much for all the help.

Al Niessner



"Martin v. Loewis" wrote:

> > So, how do I make the symbols 'T' instead of 't'?
>
> For the _GLOBAL_ symbols, the compiler decides whether to make them
> static or not in gcc/cp/decl2.c:
>
> #if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
>   /* It can be a static function as long as collect2 does not have
>      to scan the object file to find its ctor/dtor routine.  */
>   TREE_PUBLIC (current_function_decl) = 0;
> #endif
>
> Since they apparently got static, I conclude that
> ASM_OUTPUT_CONSTRUCTOR is defined for your platform. It would be
> really good if you had provided assembler output for a simple example
> like
>
> struct A{A();};
> A a;
>
> which would show what exactly the generated assembler code look
> like. You can ask gcc to generate assembler code with the -S option.
>
> On my platform (i586-pc-linux-gnu) it generates a fragment
>
> _GLOBAL_.I.a:
>   ... here is the initialization of a
> .section        .ctors,"aw"
>   .long    _GLOBAL_.I.a
>
> The section statement is the result of my target defining
> ASM_OUTPUT_CONSTRUCTOR. On Linux, all constructor functions go into a
> section .ctors. All those sections are combined by the linker to a
> single section, which is at run-time processed from crtbegin.o, as
> part of the .init processing. .init is an ELF section which is
> automatically executed by the operating system before executing the
> program entry.
>
> > I compiled the code using the Solaris platform (g++ 2.7.2) targetted for
> > VxWorks and everything works fine. I then reran "munch" which goes
> > through the libx.a file and extracts the globals and puts them in a C
> > accessable ctor/dtor file for compiling with a c compiler -- I am told
> > this is a need of VxWorks.
>
> Are you sure you really *need* to run "munch"? This is a historical
> alternative for executing constructors, and it indeed needs the
> symbols exported. Of course, if you have a real constructor section,
> then the system could (and should) collect the ctors from the .ctors
> section, not because their names start with _GLOBAL_.
>
> If your target really does not support a true ctors section, then it
> appears that it was incorrect to define ASM_OUTPUT_CONSTRUCTOR for
> it. You need to locate the place where this is defined, and correct it
> accordingly.
>
> If you cannot find that place, you can also remove the line from
> cp/decl.c as a work-around.
>
> Regards,
> Martin

Re: gcc symbol names

[Martin v. Loewis]

> I asked around about VxWorks handling the ctors section and the prevailing
> thought was no it won't.

In that case, it looks like a genuine bug in the VxWorks configuration
files of the official gcc. WindRiver may be using different
configuration files - it might be worthwhile checking their
sources. I'm not sure what the bottom of the problem is - I see
vxppc.h includes rs6000/sysv4.h. Perhaps there are other features
claimed to work by sysv4.h which aren't available in VxWorks?

Anyway, would you care to produce a patch for gcc to fix this bug?
Please send it to gcc-patches@gcc.gnu.org.

Regards,
Martin

Re: gcc symbol names

[Martin v. Loewis]

> I asked around about VxWorks handling the ctors section and the prevailing
> thought was no it won't.

In that case, it looks like a genuine bug in the VxWorks configuration
files of the official gcc. WindRiver may be using different
configuration files - it might be worthwhile checking their
sources. I'm not sure what the bottom of the problem is - I see
vxppc.h includes rs6000/sysv4.h. Perhaps there are other features
claimed to work by sysv4.h which aren't available in VxWorks?

Anyway, would you care to produce a patch for gcc to fix this bug?
Please send it to gcc-patches@gcc.gnu.org.

Regards,
Martin

Re: gcc symbol names

[Al Niessner]

I compiled the struct A sample and sure enough it was using the ctors
section. So I undefined ASM_OUTPUT_CONSTRUCTOR and it all works fine now.
Thank you very much.

I asked around about VxWorks handling the ctors section and the prevailing
thought was no it won't. It, the OS itself, really only understands C and the
munch is to merge the C to C++. For instance, when a library (.so) is loaded
in VxWorks, any of the methods are accessible through a direct call at the
command line and main() is not allowed. The loader in VxWorks is the one, I
believe, that still has no clue about ctor sections. So I have to stick with
munch.

Thanks very much for all the help.

Al Niessner



"Martin v. Loewis" wrote:

> > So, how do I make the symbols 'T' instead of 't'?
>
> For the _GLOBAL_ symbols, the compiler decides whether to make them
> static or not in gcc/cp/decl2.c:
>
> #if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
>   /* It can be a static function as long as collect2 does not have
>      to scan the object file to find its ctor/dtor routine.  */
>   TREE_PUBLIC (current_function_decl) = 0;
> #endif
>
> Since they apparently got static, I conclude that
> ASM_OUTPUT_CONSTRUCTOR is defined for your platform. It would be
> really good if you had provided assembler output for a simple example
> like
>
> struct A{A();};
> A a;
>
> which would show what exactly the generated assembler code look
> like. You can ask gcc to generate assembler code with the -S option.
>
> On my platform (i586-pc-linux-gnu) it generates a fragment
>
> _GLOBAL_.I.a:
>   ... here is the initialization of a
> .section        .ctors,"aw"
>   .long    _GLOBAL_.I.a
>
> The section statement is the result of my target defining
> ASM_OUTPUT_CONSTRUCTOR. On Linux, all constructor functions go into a
> section .ctors. All those sections are combined by the linker to a
> single section, which is at run-time processed from crtbegin.o, as
> part of the .init processing. .init is an ELF section which is
> automatically executed by the operating system before executing the
> program entry.
>
> > I compiled the code using the Solaris platform (g++ 2.7.2) targetted for
> > VxWorks and everything works fine. I then reran "munch" which goes
> > through the libx.a file and extracts the globals and puts them in a C
> > accessable ctor/dtor file for compiling with a c compiler -- I am told
> > this is a need of VxWorks.
>
> Are you sure you really *need* to run "munch"? This is a historical
> alternative for executing constructors, and it indeed needs the
> symbols exported. Of course, if you have a real constructor section,
> then the system could (and should) collect the ctors from the .ctors
> section, not because their names start with _GLOBAL_.
>
> If your target really does not support a true ctors section, then it
> appears that it was incorrect to define ASM_OUTPUT_CONSTRUCTOR for
> it. You need to locate the place where this is defined, and correct it
> accordingly.
>
> If you cannot find that place, you can also remove the line from
> cp/decl.c as a work-around.
>
> Regards,
> Martin

Re: gcc symbol names

[Martin v. Loewis]

> So, how do I make the symbols 'T' instead of 't'?

For the _GLOBAL_ symbols, the compiler decides whether to make them
static or not in gcc/cp/decl2.c:

#if defined(ASM_OUTPUT_CONSTRUCTOR) && defined(ASM_OUTPUT_DESTRUCTOR)
  /* It can be a static function as long as collect2 does not have
     to scan the object file to find its ctor/dtor routine.  */
  TREE_PUBLIC (current_function_decl) = 0;
#endif

Since they apparently got static, I conclude that
ASM_OUTPUT_CONSTRUCTOR is defined for your platform. It would be
really good if you had provided assembler output for a simple example
like

struct A{A();};
A a;

which would show what exactly the generated assembler code look
like. You can ask gcc to generate assembler code with the -S option.

On my platform (i586-pc-linux-gnu) it generates a fragment 

_GLOBAL_.I.a:
  ... here is the initialization of a
.section        .ctors,"aw"
  .long    _GLOBAL_.I.a

The section statement is the result of my target defining
ASM_OUTPUT_CONSTRUCTOR. On Linux, all constructor functions go into a
section .ctors. All those sections are combined by the linker to a
single section, which is at run-time processed from crtbegin.o, as
part of the .init processing. .init is an ELF section which is
automatically executed by the operating system before executing the
program entry.

> I compiled the code using the Solaris platform (g++ 2.7.2) targetted for
> VxWorks and everything works fine. I then reran "munch" which goes
> through the libx.a file and extracts the globals and puts them in a C
> accessable ctor/dtor file for compiling with a c compiler -- I am told
> this is a need of VxWorks.

Are you sure you really *need* to run "munch"? This is a historical
alternative for executing constructors, and it indeed needs the
symbols exported. Of course, if you have a real constructor section,
then the system could (and should) collect the ctors from the .ctors
section, not because their names start with _GLOBAL_.

If your target really does not support a true ctors section, then it
appears that it was incorrect to define ASM_OUTPUT_CONSTRUCTOR for
it. You need to locate the place where this is defined, and correct it
accordingly.

If you cannot find that place, you can also remove the line from
cp/decl.c as a work-around.

Regards,
Martin

Re: gcc symbol names

[Al Niessner]

So, how do I make the symbols 'T' instead of 't'?

The long story:

I have recompiled the ACE/TAO libraries with the cross compiler and they
have missing symbol problems too.  As I looked deeper into it I found
something interesting: The 't' does matter. Turns out all of the missing
symbols are those marked with 't' instead of 'T' like in the old
compiler.

I compiled the code using the Solaris platform (g++ 2.7.2) targetted for
VxWorks and everything works fine. I then reran "munch" which goes
through the libx.a file and extracts the globals and puts them in a C
accessable ctor/dtor file for compiling with a c compiler -- I am told
this is a need of VxWorks. The output looks like:

/* ctors and dtors arrays -- to be used by runtime system */
/*   to call static constructors and destructors          */
/*                                                        */
/* NOTE: Use a C compiler to compile this file. If you    */
/*       are using GNU C++, be sure to use compile this   */
/*       file using a GNU compiler with the               */
/*       -fdollars-in-identifiers flag.                   */


void
_GLOBAL_$I$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi();

void
_GLOBAL_$I$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment();

extern void (*_ctors[])();
void (*_ctors[])() =
    {

_GLOBAL_$I$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi,


_GLOBAL_$I$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment,

    0
    };

void
_GLOBAL_$D$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment();

void
_GLOBAL_$D$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi();

extern void (*_dtors[])();
void (*_dtors[])() =
    {

_GLOBAL_$D$_narrow__Q213Dmc1308Module17Dmc1308ControllerP12CORBA_ObjectR17CORBA_Environment,


_GLOBAL_$D$hash__56TAO_Dmc1308Module_Dmc1308Controller_Perfect_Hash_OpTablePCcUi,

    0
    };

I then removed the libx.a file, all of the .o files and recompiled with
linux platform (g++ egcs 1.1.2) targetted for VxWorks. The ctor/dtor
file looks the same as the one above. It even compiles just fine. I did
an nm on the Solaris compiled ctor.o and the Linux ctor.o and they are
identical (the __FV on the symbols in previous posts was because I was
using g++ instead of gcc).

The problem comes at ld time. When the .so is build the linker magic
fails and on the Linux platform the symbols remain undefined. I then
deleted all of the generated files and recompiled with the Solaris
platform. I then used the Linux platform to ar, munch, and ld. The
resultant .so works flawlessly.

So, how do I make the symbols 'T' instead of 't'?

I read through ld man page and did not see a switch that would help me
to override the local/global status -- probably a good thing -- but I
think it is a problem with my build of gcc.

Any and all is appreciated.

And many thanks to Martin for all of his help.


Al Niessner


Oh, and Martin, I did look at the info page, but I did not read it. I
scanned the man page looking for what I wanted and did not see it amidst
the switches. I then tried the info page and when I saw all of those
letters I incorrectly thought they were switches and ignored them. Well,
needless to say, I have read them now.  Hopefully I will not do that
again because it is rather foolish.


Martin wrote:

>> The second column of nm (first column in the text below) the case of
>> the letter is different (neither the man nor info tell me what it is
>> supposed to mean) or just different letters.

> You didn't really look, did you? In by binutils info page, on
> (binutils)nm
>
>    `T'
>          The symbol is in the text (code) section.
>
>                                                         If lowercase,
>      the symbol is local; if uppercase, the symbol is global
(external).
>
> So the symbol is global in one case, and local in the other. That
> should not be a problem, provided the linker magic for global object
> construction continues to work. Since it should be an ELF target,
> making the symbols local is the right thing to do.
>
> The difference in 'g' vs 'b' is between
>
>     `G'
>           The symbol is in an initialized data section for small
>           objects.  Some object file formats permit more efficient
>           access to small data objects, such as a global int variable
>           as opposed to a large global array.
>     `B'
>           The symbol is in the uninitialized data section (known as
>           BSS).
>
> so that should not matter, either. Also asso_values.8464 is a
> synthetic name indicating generated for a local variable; the
> numbering may have changed for some reason, but it should not be
> relevant (unless the function is inline).
>
>>  Any suggestions on how to resolve these last few issues?
>
> Why do you need to resolve them?
>
> Anyway, coming back to my earlier point: You really should recompile
> all those libraries, as nobody will give you a guarantee that they
> continue to work even if you manage to link them.
>
> Martin