|
|
When the link editor resolves an external reference in a program, it gets the address of the referenced symbol from the host library. A static linking loader like ld binds symbols to addresses during link editing. In this way, the a.out file for the program has an address for each referenced symbol.
If non-shared library code is updated and the address of a symbols changes, the a.out file will still run, since that file already has a copy of the code defining the symbol. However, that type of change can adversely affect an a.out file built with a shared library. This file has only a single symbol telling where the required library code is. Therefore, if the a.out file runs after a change, the operating system could bring in the wrong code.
To avoid this, two options are available. The first is to recompile the library after each update. The second is to implement the shared library with a branch table. A branch table associates text symbols with absolute addresses. Each address labels a jump instruction to the address of the code defining a symbol. Instead of being directly associated with the addresses of code, text symbols have addresses in the branch table.
``A branch table in a shared library''
shows two a.out files executing a call to
printf(S).
The process on the left was built using a non-shared library.
It already has a copy of the library code defining the
printf symbol.
The process on the right was built using a shared library.
This file references an absolute address (10) in the branch
table of the shared library at run time; at this address, a jump
instruction references the needed code.
A branch table in a shared library
Data symbols do not have a mechanism to prevent a change of
address between shared libraries.
The tool
chkshlib(CP)
compares a.out files
with a shared library to check compatibility and help you
decide if the files need to be recompiled.
See
``Checking versions of shared libraries using chkshlib(CP)''.