monica@srchtec.searchtech.com (Monica Skidmore) (02/08/91)
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
jat@xavax.com (John Tamplin) (02/11/91)
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
monica@srchtec.uucp (Monica Skidmore) (02/15/91)
In article <1991Feb11.034536.10212@xavax.com> jat@xavax.com (John Tamplin) writes: >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. We have tried to use collect, but we are having trouble getting it to compile on our SUN 3. There are several macros which should expand to assembly language which are undefined. Does anyone know how we should define these macros? -- ---- Monica D. Skidmore monica@searchtech.com search technology, inc. emory!stiatl!srchtec!monica Atlanta, Georgia monica@srchtec.uucp
thor@thor.atd.ucar.edu (Richard Neitzel) (02/15/91)
monica@srchtec.uucp (Monica Skidmore) writes: >We have tried to use collect, but we are having trouble getting it to >compile on our SUN 3. There are several macros which should expand to >assembly language which are undefined. Does anyone know how we should >define these macros? Try adding: #ifdef sun #define ASM_INT_OP ".long" #endif And modify the output macros to read: #ifndef ASM_OUTPUT_INT_CONST #define ASM_OUTPUT_INT_CONST(FILE,VALUE) \ fprintf(FILE,"\t%s\t%d\n", ASM_INT_OP, VALUE) #endif #ifndef ASM_OUTPUT_LABELREF_AS_INT #define ASM_OUTPUT_LABELREF_AS_INT(FILE,NAME) \ (fprintf(FILE,"\t%s\t", ASM_INT_OP), \ ASM_OUTPUT_LABELREF(FILE,NAME), \ fprintf(FILE,"\n")) #endif The tabs are needed in place of spaces to keep the assembler from choking. -- Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjo'i med sitt shinn 303-497-2057 jagar borni inn.