shared libraries

[mo at lbl-csam]

From:  Mike O'Dell [system] <mo at lbl-csam>

In general, I think Unix has gotten along quite well without 
shared libraries, running on very small machines (dual rk05 systems
have 5-megs total), and should probably continue to do so.

While shared libraries do have some useful things going for them,
they also have one extreme liability:  everyone using the
shared library gets ALL of the library, even when they only use
small parts of it.  On machines with 16-bit program counters,
this can be disastrous.  Example: no way will VI run without overlays
on non-split I/D machines if all of STDIO gets loaded.  This is not
a bad example since it is probably one of the heavier used programs
at many  installations and would probably be expected to benefit
a great deal. It seems to me that the machines which can support it
easiest (eg, VAX) usually need it the least: VAXen usually don't run
from 10-meg winnies (modulo the dual-RL02 730).  RSX on the PDP-11
has had shared paritions (which can be readonly, or read-write)
since T=0, but shared libraries aren't used too terribly much as a
general facility (like sharing STDIO, etc; but they are used a great deal
for other things) because of the large granularity of memory management
on the PDP-11 (8K bytes).

This might be mitigated, however, by the large-address-space micros like
the 68K and the 16K.  In that case, you either get to do a general memory
sharing scheme, or do a special case hack.  If a hack is proposed, I have
some suggestions.

One way would be to add a new magic number for a.out files.  This number
says to load at the address specified in the header, but share the first
ZZ bytes (determined from the header or as a system constant) with other
programs having the same magic number.  The "real" text segment could still
be shared with a little extra work.  The scheme is to then package the Library
code with the C startup code which is then loaded at the front of the
a.out.  This would let the normal loader work fine without any special
hacks - with the possible exception to add a flag which says to start loading
at a certain address (4.x already has this), and a flag to generate
the appropriage magic number. The cc command would by default then generate
an ld command which says

	ld -Z sharedcrt0.o -T<ZZ> main.o user1.o user2.o ...

The -Z flag says to generate this new magic number.
There would have to be some way to get this shared part initialized.
Probably the easiest way would be for something out /etc/rc
load code into the shared area with a shared magic number.  The stuff is then
administered like stick-bit text.

What is wrong with this??  Lots of things.

It isn't general - there are provisions for only one such shared library.
One solution would be to add another word (somewhere!) which indicates which
shared first piece is being used, and keep track of multiple pieces, but that
doesn't really solve the problem of them all loading in the same place.
It also doesn't solve the problem of a shared read-write segment, which
one would like to see done if going to all this trouble.  A shared paritition
scheme like RSX uses could certainly be done, and could be supported by
the current loader without too much work, but if you have ever seen an
RSX-11 Task Builder input file, you know the evils which must be strenously
avoided.

Again, the whole issue of shared libraries sounds like a special-case
hack one does when he is out of some critical resource: eg, disk or
physical memory, but both of those are getting cheaper almost infinitely
faster than programmer time.  So I would argue that this is NOT
a feature which belongs in Unix for the future, but might well be
a hack I would put into my own system running on toy disks, or possibly
into a system like Xenix which is specifically targeted to run on
radically-underconfigured machines.

	Save me Rob, save me!!!
	-Mike