dympl_util - Dynamic Object Module Mapping/Loading Utilities

The DYMPL_UTIL functions implement a (hopefully) portable interface to the underlying operating system facility for dynamically loading and linking object modules. The following platforms are supported:

• SunOS (and Solaris and OSF/1, apparently)
• HP/UX (untested)
• VMS
• VxWorks

Because the system-level interfaces for dynamic loading in these operating systems vary significantly, the DYMPL utilities provide a minimal interface to the system facility. Consequently, the user should be aware of the idiosyncrasies of the operating systems on which these utilities will be used; see the notes below.

The DYMPL utilities provide the following capabilities (in so far as the operating system supports them):

1. Load an object module at run-time.
2. Lookup the value of a symbol (e.g., the entry point for a function).
3. Unload a loaded object module.

To illustrate, the following fragment of code loads an object module, my_module.o, and calls the initialization function defined within that module:

    #include  "dympl_util.h"		-- Dynamic Mapping/Loading definitions.
    ...
    int  (*initializationFunction)() ;
    ObjModule  module ;
    ...
    dympl_load ("my_module.o", NULL, &module) ;
    dympl_lookup (module, "my_initialize", NULL, &initializationFunction) ;
    initializationFunction (...) ;
    ...

Notes

HP/UX

HP/UX provides the most flexible support (i.e., the most options) for dynamic loading with its shl_load(3X) routines. The DYMPL interface to these routines is as yet untested.

SunOS, Solaris, OSF/1

The manual page for dlopen(3X) says that _init and _fini functions defined in an object module are executed when the module is loaded and unloaded, respectively. I did not observe this behavior; init and fini functions in my test object module were not automatically called.

A loaded object module can lookup its own symbols by passing a NULL handle to dlsym(3X). I'm still thinking about how to handle that, no pun intended, in dympl_lookup().

VMS

My first introduction to dynamic loading under VMS was from a USENET News posting (or an FTP file, maybe) by George Carrette (of SIOD fame!) when he was working for MITECH Corporation in Concord, Massachusetts. His message contained an excellent discussion of why you would want to dynamically load object modules, a thorough description of how to prepare object modules for loading, and the C code for a simplified interface to VMS's LIB$FIND_IMAGE_SYMBOL() function.

LIB$FIND_IMAGE_SYMBOL() combines the load and lookup functions in one call. Consequently, dympl_load() simply saves the object module name; a load error won't be detected until dympl_lookup() is called. There is no support for unloading an object module.

Note that the object file name must be a strict file name (no directory or extension allowed) or a logical name. dympl_load()'s "-path specification" option takes advantage of an undocumented 4th argument to LIB$FIND_IMAGE_SYMBOL(). (I found out about it from Mr. Carrette's code.)

VxWorks

All symbols from all object modules are stored in a global symbol table. Consequently, if you load an arbitrary object module and lookup _printf, the lookup will always succeed because printf(3) is a system function. I haven't yet figured out how to restrict the lookup to only those symbols defined by the object module.

Attempting to unload a loaded object module from within my test program resulted in a text in use error. An unld at the command line produced the same error. More investigation is required.

If you disregard the global debug flag, all of the DYMPL functions are reentrant under VxWorks.

Public Procedures

dympl_load() - loads an object module.

dympl_lookup() - looks up a symbol's value in a loaded object module.

dympl_unload() - unloads an object module.

Source Files

dympl_util.c

dympl_util.h