Loads and binds an object module into the current process.
int *load (FilePath, Flags, LibraryPath) char *FilePath; uint Flags; char *LibraryPath;
The load subroutine loads the specified module into the calling process's address space. A module is an object file that may be a member of an archive. Unlike the exec subroutine, the load subroutine does not replace the current program with a new one. Instead, it loads the new module into the process private segment at the current break value and the break value is updated to point past the new module.
The exec subroutine is similar to the load subroutine, except that the exec subroutine does not have an explicit library path parameter; it has only the LIBPATH environment variable. Also, the LIBPATH variable is ignored when the program using the exec subroutine has more privilege than the caller, for example, in the case of an suid program.
If the calling process later uses the unload subroutine to unload the object file, the space is unusable by the process except through another call to the load subroutine. If the kernel finds an unused space created by a previous unload, it reuses this space rather than loading the new module at the break value. Space for loaded programs is managed by the kernel and not by any user-level storage-management routine.
A large application can be split up into one or more module s in one of two ways that allow execution within the same process. The first way is to create each of the application's modules separately and use load to explicitly load a module when it is needed. The other way is to specify the relationship between the modules when they are created by defining imported and exported symbols.
Modules can import symbols from other modules. Whenever symbols are imported from one or more other modules, these modules are automatically loaded to resolve the symbol references if the required modules are not already loaded, and if the imported symbols are not specified as deferred imports .These modules can be archive members in libraries or separate object files and can have either shared or private object file characteristics that control how and where they are loaded.
Shared modules (typically members of a shared library archive) are loaded into the shared library region, when their access permissions allow sharing, that is, when they have read-other permission . Shared modules without the required permissions for sharing and private modules are loaded into the process private region.
When the loader resolves a symbol, it uses the file name recorded with that symbol to find the module that exports the symbol. If the file name contains any / (slash) characters, it is used directly and must name an appropriate object file (or archive). However, if the file name is a base name (contains no / characters), the loader searches the directories specified in the default library path for an object file (or archive) with that base name.
The LibraryPath is a string containing one or more directory path names separated by colon s . If the base name is not found, the search continues, using the library path specified in the object file containing the symbol being resolved (normally the library path specified to the ld command that created the object file). The first instance of the base name found is used. An error occurs if this module cannot be loaded or does not export a definition of the symbol being resolved.
The default library path may be specified using the LibraryPath parameter. If not explicitly set, the default library path may be obtained from the LIBPATH environment variable or from the module specified by the FilePath parameter. If the L_LIBPATH_EXEC flag is specified, then the library path used at process exec time is prepended to any other library path specified in the load call.
(This paragraph only applies to AIX 4.3.1 and previous releases.) When a process is executing under ptrace control, portions of the process's address space are recopied after the load processing completes. For a 32-bit process, the main program text (loaded in segment 1) and shared library modules (loaded in segment 13) are recopied. Any breakpoints or other modifications to these segments must be reinserted after the load call. For a 64-bit process, shared library modules are recopied after a load call. The debugger will be notified by setting the W_SLWTED flag in the status returned by wait, so that it can reinsert breakpoints.
(This paragraph only applies to AIX 4.3.2 and later releases.) When a process executing under ptrace control calls load, the debugger is notified by setting the W_SLWTED flag in the status returned by wait. Any modules newly loaded into the shared library segments will be copied to the process's private copy of these segments, so that they can be examined or modified by the debugger.
If the program calling the load subroutine was linked on 4.2 or a later release, the load subroutine will call initialization routines (init routines) for the new module and any of its dependents if they were not already loaded.
Modules loaded by this subroutine are automatically unloaded when the process terminates or when the exec subroutine is executed. They are explicitly unloaded by calling the unload subroutine.
Upon successful completion, the load subroutine returns the pointer to function for the entry point of the module. If the module has no entry point, the address of the data section of the module is returned.
If the load subroutine fails, a null pointer is returned, the module is not loaded, and errno global variable is set to indicate the error. The load subroutine fails if one or more of the following are true of a module to be explicitly or automatically loaded:
This subroutine is part of Base Operating System (BOS) Runtime.
The dlopen subroutine, exec subroutine, loadbind subroutine, loadquery subroutine, ptrace subroutine, unload subroutine.
The ld command.
The Shared Library Overview and Subroutines Overview in AIX Version 4.3 General Programming Concepts: Writing and Debugging Programs.