Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!lll-lcc!rutgers!husc6!harvard!ksr!alcatraz!benson From: benson@alcatraz.ksr.com (Benson Margulies) Newsgroups: comp.arch Subject: Re: implementing shared libraries Message-ID: <82@ksr.UUCP> Date: Tue, 28-Apr-87 07:28:10 EDT Article-I.D.: ksr.82 Posted: Tue Apr 28 07:28:10 1987 Date-Received: Wed, 29-Apr-87 07:21:58 EDT References: <12823@watnot.UUCP> <926@aw.sei.cmu.edu.sei.cmu.edu> <7952@utzoo.UUCP> Sender: nobody@ksr.UUCP Reply-To: benson@ksr.UUCP (Benson Margulies) Organization: Kendall Square Research, Cambridge MA Lines: 69 In article <7952@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> Far and away the simplest way is for the compiler to generate >> Position Independent Code. The libraries can then reside at >> any place in the process' virtual address space. They need not >> be at the same place in all processes. > >Don't forget the problems of (a) where does static data for the library >functions live (they need to know this), and (b) how does the user code >find out where the foobar() function is. I think the latter is more what >the original question was about. >-- Cripes, folks, you have been beating around the bush of dynamic linking for weeks now. In the interest of calling a personal earth moving device a spade, I'll sketch the mechanism. Now that Unix runs on computers more like the power of its original parent, perhaps its time for it to recapture some non-chewing-gum-and-bailing-wire system technology from its own history. one scheme works like this: Each object file is structured into four pieces: text definitions static linkage symbol There has to be as storage allocation mechanism independent of "running" a program. Text references to external quantities are references through pointers in the linkage. The initial copy of the linkage contains pointers that take a fault when you reference through them. (your hardware does have such minimal amenities, right? If not, put a trap instruction in the linkage, and have the text jump there). When the fault handler takes one of these linkage faults, it makes a copy of the entire linkage section in per-process storage (on Unix you may want it to be per-group-leader or something), and fixes the faulting pointer to point to the linked-to library routine, using naming information in the definitions section of both the referencer and the referencee. Once you have that, you are on the air with no further faults. Static lives in the static section. All references to static are addressed as offsets from a pointer stored in a table. When a file is first linked to in a process, the static section is copied, and the pointer initialized. Thus, each process gets its own static. Manifestly, this is easier to do in a segmented environment than a flat environment, but that shouldn't stop you for long. Someone's comments about strcopy in shared memory are a red herring. In systems with "shared memory", the vast bulk of the shared data is pure code. As soon as you go to share something that is modifiable, you are in the synchronization business. You use locks, semaphores, or whatever you like. That's what shared data is all about. When I worked on Multics, that's most of what I did was write shared memory programs, and anyone out there working on Multiprocessor Unix is doing the same thing. Benson I. Margulies Kendall Square Research Corp. harvard!ksr!benson All comments the responsibility ksr!benson@harvard.harvard.edu of the author, if anyone.