Re: Smart linking under UNIX

John Levine <compilers@iecc.cambridge.ma.us> writes:
>[Any comments on dynamic linking?]


Well, I'm not a linker whiz. But dynamic linking is definitely my area, so
I'll say a few words about it. Warning: I'll make a few simplifying
assumptions.


* The designers of VMS (1970s) considered allocating 1Gb for shared
    libraries. The goal was that standard libraries would be placed at
    standard locations. However even at that time they decided that they
    would rapidly run out of address space. Not all systems would have
    all libraries, so the disk space requirements could be much less than
    1Gb, but assigning addresses across all systems would use a lot of
    address space.


* In most systems, the dynamically-linked libraries can be placed at
    any memory location. Implications: they must be position-independent
    code, and the caller (your program) doesn't know the link address
    statically (at compile/static link time).


* It is generally assumed that the text segments will not be modified
    and can thus be shared. The libraries may be mapped at different
    addresses in different processes. As a result, some kind of
    indirection is required on library calls. The one I've seen most
    commonly on RISC machines is to jump to some code in the (non-shared)
    data segment that is set at dynamic link time to jump to the target
    library routine.


* In SunOS, the code and data segments are adjacent, so a pc-relative
    reference always lets you find the library's static data. In the
    RS/6000 there is a special data segement register. On each
    library call, the data segment register must be spilled and loaded
    with the target library's data segment pointer; on return, the
    original data segment register is reload from the stack.


* In System V, each (dynamically linked) library is assigned a major
    version number and a minor version number. Each revision that
    maintains the same external interface gets a new minor number.
    Changes to the external interface get a new major number. When an
    executable is compiled, symbols are resolved but not bound, and the
    name and major and minor number of the library used to resolve the
    symbol are stored in the executable. At runtime the dynamic linker
    searches for the newest minor number with a matching major number.


* The System V dynamic linker can be told to link all libraries at
    program startup, or to link libraries incrementally. If a library is
    linked incrementally so that each function is linked to each call
    site only if it is called, and the linking is done when the routine
    is first called.


* Under System V incremental linking, the dymamic link tables are
    initialized so that a call to a not-yet-linked routine will instead
    call the dynamic linker. The dynamic linker will then map the
    library and invoke the given routine. Libraries that cause
    unresolved data referfences are mapped at program startup and the
    data references are resolved. If the newly-linked library itself
    causes an unresolved data reference, then the dependent library is
    mapped and so on.


* The System V dynamic linker has a search path for libraries. In
    addition, the user may set an environment variable that adds to the
    search path. For suid programs, the user-defined search path is
    ignored.


* In SunOS, when a library is found, the library is mapped in to the
    process's address space, but pages are not brought in to memory until
    they are referenced. Pages may already be in memory if another
    process has been using that library.


* Incremental update is tricky because e.g., the process may get a
    signal and try to call library function X at the same time that the
    dymamic linker is trying to resolve function X.


* In System V, the dynamic linker is an interpreter in the sense that
    all programs starting with the `#!' magic number are interpreters.
    However, in SunOS, a special magic number is used. Dymamiclly-linked
    programs are scripts so that the dymamic linker is started before the
    program starts executing.


* All System V-compliant application programs are required to import
    certain machine-specific information using the dynamic linker.




To summarize:


* Shared libraries can be mapped at different addresses in different
    processes. Thus, the routine addresses are not known at static link
    time and the library must use position-independent code.
* Dymamic linking can be done entirely on program startup, or can be
    incremental so the full linking cost is only paid for routines that
    are actually called during a given execution of the program.
* Dynamically linking external static data requires binding at startup.
* Version control is via major and minor numbers. A system must keep
    all major numbers needed by all programs on the given system.
* Libraries are searched at compile time so unresolved symbols can be
    detected staically.
* The same library is discovered dymamically using a library name and
    a search path.




I think that covers most of the major points. For further information,
see:


%Q AT&T
%T System V Application Binary Interface
%D 1990
%I Prentice-Hall
%P 5-12 to 5-21


%Q AT&T
%T System V Application Binary Interface SPARC Processor Supplement
%D 1990
%I Prentice-Hall
%P 5-1 to 5-11


;-D oN ( The missing link ) Pardo
[The System V libraries mentioned above are the V.4 ones that are almost but
not quite compatible with the ones in SunOS. V.3.2 has an awful reserved
address scheme similar to the one rejected for VMS. -John]
--

Return to the comp.compilers page.
Search the comp.compilers archives again.