an alternative view of memory management [really = shared libs]
John Mashey
mash at mips.UUCP
Fri Jan 17 17:42:19 AEST 1986
> 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
More information about the Comp.unix
mailing list