From: CRDGW2::CRDGW2::MRGATE::"SMTP::PREP.AI.MIT.EDU::HELP-G++-REQUEST" 10-MAR-1991 09:47:29.70 To: ARISIA::EVERHART CC: Subj: Re: initialization with g++ and vxWorks From: help-g++-request@prep.ai.mit.edu@SMTP@CRDGW2 To: Everhart@Arisia@MRGATE Received: by crdgw1.ge.com (5.57/GE 1.83) id AA29776; Wed, 13 Feb 91 11:09:14 EST Received: by life.ai.mit.edu (4.1/AI-4.10) id AA09772; Sun, 10 Feb 91 23:46:13 EST Return-Path: Received: from tut.cis.ohio-state.edu by life.ai.mit.edu (4.1/AI-4.10) id AA09700; Sun, 10 Feb 91 23:45:25 EST Received: by tut.cis.ohio-state.edu (5.61-kk/5.910130) id AA12614; Sun, 10 Feb 91 23:44:16 -0500 Received: from USENET by tut.cis.ohio-state.edu with netnews for help-g++@prep.ai.mit.edu (help-g++@prep.ai.mit.edu) (contact usenet@tut.cis.ohio-state.edu if you have questions) Date: 11 Feb 91 03:45:36 GMT From: xavax!jat@uunet.uu.net (John Tamplin) Organization: Xavax Subject: Re: initialization with g++ and vxWorks Message-Id: <1991Feb11.034536.10212@xavax.com> Sender: help-g++-request@prep.ai.mit.edu To: help-g++@prep.ai.mit.edu In article <1991Feb8.150548.25891@srchtec.uucp> monica@srchtec.searchtech.com (Monica Skidmore) writes: >We are running vxWorks 4.0 (soon to be upgraded to vxWorks 5.0) on >68030 processors. We are using C++, compiled on a SUN 380 for the >processors, and are in the process of changing from AT&T's cfront >to gnu g++ 1.37.0. Our problem is that the initialization of user >defined objects that are globally visible is not done when the code >is run under vxWorks. We were able to solve this problem with cfront >by running the .o files through nm and munch, relinking that output >to our original file, and inserting our own calls to >_intialize_static_data() in our "main" program. > >We know that gcc-ld normally performs the corresponding functions for >gnu g++, but when we compile for vxWorks rather than Unix, the >initialization code is not generated. (We suspect it is suppressed by >the -r option to the linker.) We have tried to compile the gnu >collect.c program to perform this function, but we do not know how to >define the assembly code macros it uses for our machine. > >Can anyone tell us how to solve this problem? Are we on the right >track with collect, or are is there a certain combination of gcc-ld >options that we should use? > > >-- >---- >Monica D. Skidmore monica@searchtech.com >search technology, inc. emory!stiatl!srchtec!monica >Atlanta, Georgia monica@srchtec.uucp I have done the same thing (except for standalone code on 68020 instead of vxWorks, and cross compiled from an 88k). You really should use gnu-ld -- without collect. gnu-ld just collects the list of static constructors and destructors for you -- the functions to actually create and destroy these objects are called from main(). g++ inserts the code into your main routine. If vxWorks arranges to call main for you, you are all set once you use gnu-ld to do your final link. If you are doing the final link under vxWorks, you will need to run collect over the output. If neither of these cases apply, then you will need to do it yourself in the startup routine. Here is a snipet of code from my startup code for the embedded o/s: (gas syntax) ... | init C++ objects lea ___DTOR_LIST__,a0 | set up linked list movl a0@,___dli movl a0,___dlp jbsr ___do_global_init | start tasking jbsr _starttasking | kill C++ objects jbsr ___do_global_cleanup ... |---------------------------------------------------------------------- | the following is to ensure that at least one static constructor and | at least one static destructor exist |---------------------------------------------------------------------- dctor: rts ddtor: rts .stabs "___CTOR_LIST__",22,0,0,dctor .stabs "___DTOR_LIST__",22,0,0,ddtor The last part is not absolutely necessary, but otherwise you will get undefined symbols if there are no static objects. Hope this helps. -- John Tamplin Xavax jat@xavax.COM 2104 West Ferry Way ...!uunet!xavax!jat Huntsville, AL 35801