an alternative view of memory management [really = shared libs]

[John Mashey]

> 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