From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Niessner To: egcs@cygnus.com Cc: gcc-help@gcc.gnu.org Subject: Re: gcc symbol names Date: Wed, 01 Mar 2000 19:26:00 -0000 Message-id: <38BDDFE3.B53E2520@bigfoot.com> References: <38BC9759.EC41E8AE@bigfoot.com> <200003010907.KAA00727@loewis.home.cs.tu-berlin.de> X-SW-Source: 2000-03/msg00007.html 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Al Niessner To: egcs@cygnus.com Cc: gcc-help@gcc.gnu.org Subject: Re: gcc symbol names Date: Sat, 01 Apr 2000 00:00:00 -0000 Message-ID: <38BDDFE3.B53E2520@bigfoot.com> References: <38BC9759.EC41E8AE@bigfoot.com> <200003010907.KAA00727@loewis.home.cs.tu-berlin.de> X-SW-Source: 2000-q1/msg00317.html Message-ID: <20000401000000.oTtwUGRRrvKvxsXYogaZ70jSVRSlS88210EbMYKWbhE@z> 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