Re: gcc symbol names

[Al Niessner <Al_Niessner at bigfoot dot com>]

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