The GNU C/C++ compiler has an attribute feature which can be used to mark certain routines as initialization or cleanup routines of a software module. The routine has to have a prototype of the form 'void (*) (void)'.

Unfortunately, this mechanism doesn't work without additional help under VxWorks, since this environment uses a dynamic linker to load object modules which does not recognize the above attributes. However, there is a way to do it by using the 'munching' feature which allows VxWorks to initalize static C++ constructors (see the Tornado User Guide / Cross-Development for more details).

The munching process scans the symbol table of an obejct for symbols which look like initialization or cleanup functions ('_GLOBAL_$D' and '_GLOBAL_$I'). It then generates a piece of C code which allocates two special function lists which ARE recognized by the VxWorks runtime linker. Finally, this C code is compiled and linked with the original object module. If the function 'cplusXtorSet(1)' is called before loading a module, it is initialized automatically after loading. Similarly, the cleanup functions are called before the module is unloaded.

GDS provides the macro '__init__(fn)' to declare a function prototype of name 'fn' which acts as an initialization routine. Similarly, the macro '__fini(fn)__' declares a cleanup prototype. Under VxWorks these macros define global symbols of the form '_GLOBAL__I_fn' and '_GLOBAL__D_fn', respectively. The GDS provided muching function has to be used to recognize these additional symbols and generate the function tables.

If the module should also run under Solaris using the same initailization and cleanup routines, an addtional pragma has to be added (see section: Solaris libraries).

We recommend to always use the macro and the pragma directive together.

Example:

    __init__(initModule1);
    #pragma init(initModule1)
    
    void initModule1 (void) { ... }
    

Author:

Daniel Sigg