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:
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):
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 (...) ; ...
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.
The manual page for
dlopen(3X) says that
_fini functions defined in an object module are executed
when the module is loaded and unloaded, respectively. I did not observe
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
dlsym(3X). I'm still thinking about how to handle that, no
pun intended, in
My first introduction to dynamic loading under VMS was from a USENET News
posting (or an FTP file, maybe) by
George Carrette (of
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() 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.
-path specification" option takes advantage of an
undocumented 4th argument to
(I found out about it from Mr. Carrette's code.)
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.
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.