Re: gcc symbol names

[Al Niessner <Al_Niessner@bigfoot.com>]

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