Dynamic-Loading Functions

Introduction

Although most C programs are linked together as a single load module, for large applications it is often convenient to divide a program into several load modules that can be loaded into memory and unloaded independently. The SAS/C Compiler and Library support multiple load module programs, but you must develop such programs carefully.

As with any C program, program execution always begins with a function named main . The load module containing the main function must remain in memory at all times. Each subordinate (dynamically loaded) load module must contain a function named _dynamn (which is a contraction for dynamic main). From the perspective of the compiler, the _dynamn function serves the same role in the subordinate load module as main serves in the module containing the main program.

Cautions

Note that load modules linked with the SAS/C Library are of two distinct types: main modules and dynamically loadable modules. A main module is one which contains a main function, or which can cause the C environment to be created in conjunction with using the indep compiler option. A dynamically loadable module is one which contains a _dynamn function. It is not possible to create a load module which is of both types. Any attempt to do so will fail at link time or at execution time. Two consequences of this requirement are:

You cannot link a main function and a _dynamn function into the same load module. In particular, this means that you cannot have a source file which includes both these functions.
You cannot create a C framework by calling a function that was compiled with the indep option into a load module which includes a _dynamn function.

This restriction is imposed so that dynamically loadable modules are not forced to include the large amount of code needed to create a new C framework.

Dynamic Load Modules

Load modules subordinate to the main program module can be loaded by use of the loadm and unloadm functions. The second argument to loadm is a pointer to a function pointer in which the address of the loaded _dynamn routine will be stored.

In addition to loadm and unloadm , the library provides functions to load and unload modules containing only data ( loadd and unloadd ) and a function that converts a load module entry point address to a function pointer ( buildm ). Two other functions, addsrch and delsrch , are provided, primarily for CMS, to define the load module search order. The search order consists of the possible locations of dynamically loaded modules and the order in which they are processed. Before any of these routines can be used, the source program must include the header file <dynam.h> using the #include statement.

Transfers of control between load modules are possible only by using function pointers. However, through the use of appropriate pointers, a routine in one load module can call a routine in any other load module. The inability of one load module to call another directly is a special case of a more general restriction; namely, load modules cannot share external variables. More precisely, two external variables (or functions) of the same name in different load modules are independent of each other. (There are a few special cases such as the variable errno , which contains the number of the most recent run-time problem.) See Appendix 4, "Sharing extern Variables among Load Modules," in the SAS/C Compiler and Library User's Guide for additional information. An external variable or function can be accessed directly only by functions that have been linked in that module. All functions in other modules can gain access to them only by use of pointers.

The functions for dynamic loading, especially addsrch and delsrch , are highly operating-system-dependent. The definition of each dynamic-loading function highlights aspects of the function that depend in some way on the operating system. addsrch and delsrch , for example, are of interest to users working under OS/390 only when a program needs to be portable to CMS. For CMS, these functions are quite useful but are not needed typically in an OS/390 environment.

Chapter Contents
Previous
Next
Top of Page