On Thu, 3 Dec 1998, Alistair Riddoch wrote:
; Eric J. Korpela writes:
[...]
; > Implemenation idea:
; >
; > Shared library file format is the same as object file format, except
; > no static data is allowed in the file, just code. When creating a
; > shared library, code is moved to filename.so. Static data and a bunch of
; > far call stubs are moved into a static library filename.a. This library
; > is linked with code normally. The only unresolved symbol in the program
; > are the code segments of the shared libraries.
[...]
; This sounds like a workable implementation, though I think we should put
; priority on getting the ammount of data used by processes down as this is
; currently where most of the memory is going. The only other thing is that
; most binaries currently use a tiny fraction of libc, whereas if the whole
***************************************************
I've wondered about this. If memory space is tight (and in ELKS it
may be), maybe one solution to "lean binaries" might involve a complete
re-think about libraries. If most binaries really do use only a small
fraction of libc (or libfoo, whatever), is it appropriate to reorganize
the linker to either weed out unused calls, or just never put in the
dead library code in the first place? Here's an idea --- it may or
may not be practical ---
Example:
suppose we have a program, foo.c :
---cut here---
#include <stdlib.h>
#include <stdio.h>
int main (int argc, char *argv[]) {
printf("%d\n", atoi(argv[1]) + atoi(argv[2]));
}
---cut here---
~ $ cc foo.c -c
~ $ nm foo.o
U atoi
00000000 t gcc2_compiled.
00000000 T main
U printf
~ $
So we make libc (libm, etc.) subdirectories some place where the
linker knows, say, /usr/lib, and put *.o files, one function to
a file, in the subdirectories. Each "library" so made would have
a common *.o file in which you put all the things that *absolutely*
every function in the "library" needs.
Then, linking foo.o above would automagically do this:
the user types in:
$ cc foo.c -c
$ cc foo.o
and the linker looks at required symbols in foo.o, and
behind-the-scenes does this:
$ ld foo.o /usr/lib/libc/common.o \
/usr/lib/libc/stdlib/atoi.o \
/usr/lib/libc/stdio/printf.o
and out pops 'a.out' with only the bare minimum of executable
needed to run.
Realistically, this would require modification of the
linker/compiler toolchain, which is over my head at present. :-(
; of the libc code was in the dynamic libc, then we would have more memory
; taken uyp by code. Maybe its time we split libc up into libtermcap,
; libsocket etc? Or maybe the shared libc codesegment should only contain
; some of the code libc functionality?
This approach (splitting up libc into libtermcap, etc) seems to me
like a lot less work to do than the idea I described above, since we
use the current compiler toolchain as-is.
[...]
; -Al
-lg
Louis Glassy ([EMAIL PROTECTED])
Department of Computer Science
Montana State University
Bozeman, Montana 59717 USA
