Return to BSD News archive
Xref: sserve comp.unix.bsd:12616 comp.os.linux:54636 comp.os.386bsd.misc:950 Path: sserve!newshost.anu.edu.au!munnari.oz.au!spool.mu.edu!agate!dog.ee.lbl.gov!horse.ee.lbl.gov!torek From: torek@horse.ee.lbl.gov (Chris Torek) Newsgroups: comp.unix.bsd,comp.os.linux,comp.os.386bsd.misc Subject: shared libraries (was BSD UNIX) Date: 12 Sep 1993 01:44:10 GMT Organization: Lawrence Berkeley Laboratory, Berkeley CA Lines: 47 Message-ID: <33833@dog.ee.lbl.gov> References: <michaelv.747102277@ponderous.cc.iastate.edu> <CCu0s1.29o@ssesco.com> <1993Sep7.162843.19294@fcom.cc.utah.edu> NNTP-Posting-Host: 128.3.112.15 In article <1993Sep7.162843.19294@fcom.cc.utah.edu> terry@cs.weber.edu (A Wizard of Earth C) writes: >The difference between shared and dynamic libraries boils down to when the >offset table is filled out. While load tends to be faster with dynamic, >you do take run-time hits for initial reference of routines with dynamic >binding; I consider this a loss (it *is* a performance hit that should be >taken at link time, not runtime -- an application is typically linked >once and run many times). Also, depending on implementation, you end up >either losing shared text for each fixup (if it is done wrong) or losing >shared text for the GOT for the jump-through and reference-through tables >which could otherwise be marked as shared pages after initial fixup ... (We should note that given true PC-relative addressing, `link fix-ups' or indirections through tables occur only for cross-`chunk' references, such as calls from the application to a shared library. But many CPUs make PC-relative addressing difficult.) This makes the Utah approach (as described at the last USENIX) all the more interesting. In this case, `executing' a binary invokes the linker, which can choose either to run a cached `pre-linked' version or to construct a new one. As Terry notes, most applications are run much more often than they need re-linking (the shared libraries do not change often). Hence, the same cached `post-fixup' version can be reused (saving time) and shared (saving space). In effect, this is the happy medium between `pure static' and `pure dynamic': resolved on demand, then static until something forces a change. Note that if this is done `right', the cached post-fixup binaries do not need to contain the shared libraries. Rather, the dynamic linker chooses an address for each shared library for each binary, and attempts to keep this address constant per library. If/when this attempt fails, this falls back to the equivalent of `pure dynamic' linking; when it succeeds, it works much like `pure static' linking. The only thing that the choice of per-library address `constants' affects is the ratio of successful `static-like' links to failed `dynamic-like' links. Assigning addresses to libraries would be the task of a program similar to SunOS's `ldconfig'. A library that lacks a preselected address would simply have one chosen dynamically. This would take more space, to cache `preloaded' binaries and (at their preselected addresses) libraries, but only those that are in fact used and/or only those that meet some policy. Again, the fallback is, in essence, `pure dynamic' linking; all else is merely optimization. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov