Unlinking a Module

The major difference between dld and other dynamic linkers is that dld allows object modules to be removed from the process anytime during execution. Unlinking a module is simply the reverse of the link operation (see section Unlinking a Module). The specified module is removed and the memory allocated to it is reclaimed. Additionally, resolution of external references must be undone.

There are two unlink functions:

Function: int dld_unlink_by_file (const char *path, int hard)

Function: int dld_unlink_by_symbol (const char *id, int hard)

The two unlink functions are basically the same except that dld_unlink_by_file takes as argument the path name (path) of a file corresponding to a module previously linked in by dld_link, but dld_unlink_by_symbol unlinks the module that defines the specified symbol (id).

Both functions take a second argument hard. When hard is nonzero (hard unlink), the specified module is removed from memory unconditionally. On the other hand, if hard is zero (soft unlink), this module is removed from memory only if it is not referenced by any other modules. Furthermore, if unlinking a module results in leaving some other modules being unreferenced, these unreferenced modules are also removed.

Hard unlink is usually used when you want to explicitly remove a module and probably replace it by a different module with the same name. For example, you may want to replace the system's printf by your own version. When you link in your version of printf, dld will automatically redirect all references to printf to the new version.

Soft unlink should be used when you are not sure if the specified module is still needed. If you just want to clean up unnecessary functions, it is always safe to use soft unlink.

Both unlink functions returns 0 if the specified object file or symbol is previously loaded. Otherwise, they return a non-zero error code (see section Definition of Error Codes).

Important Points in Using Unlink

When a module is being unlinked, dld tries to clean up as much as it can to restore the executing process to a state as if this module has never been linked. This clean up includes removing and reclaiming the memory for storing the text and data segment of the module, and un-defining any global symbols defined by this module.

However, side effects--such as modification of global variables, input/output operations, and allocations of new memory blocks--caused by the execution of any function in this module are not reversed. Thus, it is the responsibility of the programmer to explicitly carry out all necessary clean up operations before unlinking a module.

Go to the first, previous, next, last section, table of contents.