[220] in Release_Engineering
Notes for a Proposal for a shared global library on the IBM RT/PC.
eichin@ATHENA.MIT.EDU (eichin@ATHENA.MIT.EDU)
Mon Aug 22 01:29:09 1988
Notes for a Proposal for a shared global library on the IBM RT/PC.
The following notes are the results of discussion between John D
Kubiatowicz <kubitron>, Donald T. Davis <don>, myself <eichin>, with
additional comments from Mark Lillibridge <chariot> and William
Sommerfeld <wesommer>. They are entered here for later reference and
design work. At some point this should be cooked into a real design
proposal, and channelled through the review process.
*) allocate an entire segment for the shared libc. (We can ask Palo
Alto for this, get them to reserve us one.) This segment will be
mapped in all processes, but doesn't need any relocation work.
*) the calling conventions can be tuned to other requirements; version
numbers of various levels of complexity can be included, if fixed
offsets into a jump table are used. If an actual name lookup is done
at exec time, the version numbers might be less important.
*) another issue involved with use of fixed offsets vs. symbol tables
is the forward/backward compatibility issue; kernels should be able to
change readily without rebuilding the entire system. Also, library bug
fixes should be possible without rebuilding the client programs.
*) create a stub jump table (useful in building the library, as it has
unresolved references to *everything* and can make the linker pull it
all in)
*) use a symbol table of some sort for the library segment, or a set
of symbol tables for multiple libraries. This probably should be
designed for speed, since it would be used at every exec.
**) table at a fixed location of pointers to procedures,
unresolved. However, all calls to remote libraries are done with jump
indirect through offset into table.
**) table of jumps to remote library procedures, unresolved.
However, all calls to remote libraries are done with resolved jumps
into the table.
*) should the library be in swap space? Yes, libc is only 300K... it
should *NOT* be wired though. Let page faults bring in the pages. Look
into the existing text loading routines, and use the same techniques
to bring in the library text.
*) addlib (new system call?) `hooks up' a library to the lib segment,
and does the symbol table management.
*) Also note, that either 407 (.o magic number) or some new magic
number can be used for this type of module. Since the symbol table may
*not* be a `real' one, ie. the kernel may not grok the symbol table of
a real .o file, a new magic number is advised.
*) Should this library include more than just libc? I believe CMU is
using shared library support in Andrew, for their large libraries; it
may be effective for us to include Xlib and Xt in this library cache
in our environment.
*) A quick savings estimate: (1) There are 68 binary executables on
the RT root. Most if not all of these contain printf. Sharing printf
(and specifically ecvt, fcvt, and gcvt, and the other floating point
code) would save about 20K per executable, thus 70*20K = 1.4Meg (out
of the 5.9Meg which they occupy now.) Extrapolate to the /srvd...
[As a side note, simply castrating printf so that binaries which don't
need the floating point support (again, almost all of them) didn't
link in the floating point code would provide this benefit as well,
but with some serious Makefile management headaches.]
*) It has been pointed out (by Jerry Saltzer) that IBM development is
geared towards A/IX, which already has shared libraries. The vast
increase in executable size which was noted going from 5.5 to 6.0 can
mostly be attributed to the addition of floating point support for the
new hardware, which is getting duplicated into most of our
executables, while it sits in one place in their libraries.
[eichin:19880822.0111EST]
I believe I have covered most of the chains of thought we have
discussed in the last few weeks; if there further points, reply to
this message or mail them to me and I will include them in my notes.
Mark Eichin
<eichin@athena.mit.edu>
Project Athena ``Watchmaker''
