From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Martin v. Loewis" To: Al_Niessner@bigfoot.com Cc: gcc-help@gcc.gnu.org Subject: Re: gcc symbol names Date: Wed, 01 Mar 2000 01:18:00 -0000 Message-id: <200003010907.KAA00727@loewis.home.cs.tu-berlin.de> References: <38BC9759.EC41E8AE@bigfoot.com> X-SW-Source: 2000-03/msg00001.html > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Martin v. Loewis" To: Al_Niessner@bigfoot.com Cc: gcc-help@gcc.gnu.org Subject: Re: gcc symbol names Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-ID: <200003010907.KAA00727@loewis.home.cs.tu-berlin.de> References: <38BC9759.EC41E8AE@bigfoot.com> X-SW-Source: 2000-q1/msg00311.html Message-ID: <20000401000000.gvrC3vZqH2qWLhbX6sHqwhAndsSXO3jCxxs_sykOy5w@z> > 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