Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site mips.UUCP Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!glacier!mips!mash From: mash@mips.UUCP (John Mashey) Newsgroups: net.unix Subject: Re: an alternative view of memory management [really = shared libs] Message-ID: <291@mips.UUCP> Date: Fri, 17-Jan-86 02:42:19 EST Article-I.D.: mips.291 Posted: Fri Jan 17 02:42:19 1986 Date-Received: Sat, 18-Jan-86 09:09:57 EST References: <536@smeagol.UUCP> Distribution: net Organization: MIPS Computer Systems, Mountain View, CA Lines: 40 > Suppose (1) executable files are unlinked executables and the ".o" > files that they refer to, instead of fully linked executables, and > that (2) upon a trap to an unknown routine(), the system resolves > the address or loads in the appropriate ".o" and then resolves. > > Furthermore, a new "C" compiler and linker would be required. > > People and articles seem to indicate that the following systems are > implemented this way: Multics, AT&T 7300, National's GENIX, Apollo > DOMAIN. (Any of this list incorrect? Smalltalk is similar, but only > uses a single address space.) 1) This topic is usually called "shared libraries". There have been a fair number of discussions on this in the net. The last one I have any trace of was in May 85. Dave Brower of RTI posted a summary of comments about that time in net.arch. 2) PRIME's PRIMOS does dynamic linking, and certainly APOLLO. Both sets of those people know a lot about this topic. 3) The 7300 doesn't, exactly. See 4 below. 4) On any System V with shared memory and the full-bore COFF ld, one can do a useful (although not as dynamic) shared library without touching kernel, cc, or ld.. Basically, you link a library appropriately, setting an origin somewhere not in the usual text space. You extra the symbols and make up a ld input file that you use when linking normal programs. When the system comes up, you put the library in a shared memory region, and you tweak the C runtime startoff to attach to that memory. This is an oversimplification, and there is a tradeoff between user-level simplicity and modifying the kernel somewhat. 5) Many solutions exist with various time/space/complexity tradeoffs for the code. The nastier problem is the shared data, whose most classic problem is errno, for example. -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash DDD: 415-960-1200 USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043