gcc symbol names
Al Niessner
Al_Niessner@bigfoot.com
Sat Apr 1 00:00:00 GMT 2000
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
More information about the Gcc-help
mailing list