Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.1a 7/7/83; site rlgvax.UUCP Path: utzoo!linus!decvax!harpo!seismo!rlgvax!guy From: guy@rlgvax.UUCP (Guy Harris) Newsgroups: net.unix-wizards Subject: Re: Shared system routines Message-ID: <907@rlgvax.UUCP> Date: Wed, 27-Jul-83 15:54:41 EDT Article-I.D.: rlgvax.907 Posted: Wed Jul 27 15:54:41 1983 Date-Received: Thu, 28-Jul-83 14:30:01 EDT References: <392@alberta.UUCP> <886@rlgvax.UUCP>, <505@mit-eddie.UUCP> Organization: CCI Office Systems Group, Reston, VA Lines: 21 The way Multics solved the "global references from shared libraries" problem was to use a giant transfer vector called the "(common) linkage segment". This was also necessary for the dynamic linking. Any reference to an external of any sort went through an indirect pointer in the common linkage segment. This pointer was initially a special pointer which caused a trap, and it pointed to a character string which was the name of the external. When the fault occured due to this pointer, the OS would find the segment referenced by that pointer (using a search rule similar to PATH) and "initiate" it (i.e., map it into your address space). It would copy the prototype of its common linkage segment section into the system common linkage segment (which was also the per-process static data segment, so this copy would also initialize static variables), so any time any routine in that segment referenced an external the same fault process would occur. Then it would paste the address of the given entry point in the given segment into the pointer in the common linkage segment. Unfortunately for this scheme under UNIX, existing compilers don't produce code to reference externals through such a transfer vector (at least not on the machines I'm familiar with; I've seen references to transfer vectors on the 3B machines), so the Multics solution can't just be dropped into UNIX. Guy Harris {seismo,mcnc,we13,brl-bmd,allegra}!rlgvax!guy