Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: Shared Libraries
Message-ID: <2649@auspex.auspex.com>
Date: 20 Nov 89 21:27:59 GMT
References: <656@augean.OZ>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 85

>Is ld.so itself a shared object?

Yes.

>If so how does crt0.o get to "invoke" it before ld.so has been
>executed?

It knows where "ld.so" lives, and how to map it in, etc..  It may assume
that "ld.so" is position-independent code, so that it doesn't have to
relocate it (it is position-independent code, but I don't remember any
more whether the "crt0" code could relocate it if it weren't); "ld.so"
contains enough code of its own so that it doesn't depend on "libc" or
anything like that. 

>Secondly, does the runtime linking only involve relocation or is the
>actual code copied from the .so file to the processes address space as
>well?

It involves only relocation, and if you've build the ".so" file as
position-independent code ("-pic" or "-PIC" for C code, other options
may be available for other compilers, do it yourself for assembler
code), it requires little if any of that.

>The latter scheme would have the disadvantage that the process text
>space would not really be shared (there would be multiple copies of
>the library code in core or swap space) and start up might be slow. It
>would seem to be better if the library was mapped into the process
>virtual address space and demand paged out of the .so file.

That is exactly what happens; the run-time loader uses "mmap" to map it
into the process' address space.  It maps it copy-on-write, so that if
it *does* have to relocate any code, copies are made of the relocated
pages, and so that if you set a breakpoint in shared library code you
don't stomp on anybody else using the shared library.  (The same holds
true of the main executable image; you're not disallowed from debugging
something just because somebody else is running it.)

>This might be difficult to arrange without using up a lot of virtual address
>space.  Mapping the whole library (whether or not it is all used)
>clearly uses up a lot of virtual address space and mapping each
>function referenced would waste fragments of a page (average 1 per
>function) since the functions do not start and finish on a page
>boundary, although is would be possible to align the start of the
>functions in the .so file to page boundaries reducing the average size
>of the unused page fragments to 0.5 pages per funtion.

	Script started on Mon Nov 20 13:20:36 1989
	auspex% cat /etc/motd
	SunOS Release 4.0.3 (AUSPEX) #1: Wed Oct 4 19:00:32 PDT 1989
	auspex% arch
	sun4
	auspex% size /usr/lib/lib*.so*
	text	data	bss	dec	hex
	319488	16384	0	335872	52000	/usr/lib/libc.so.1.3
	294912	57344	632	352888	56278	/usr/lib/libcore.so.0.1
	16384	8192	0	24576	6000	/usr/lib/libkvm.so.0.3
	180224	8192	0	188416	2e000	/usr/lib/libpixrect.so.2.4
	655360	32768	0	688128	a8000	/usr/lib/libsuntool.so.0.40
	196608	16384	0	212992	34000	/usr/lib/libsunwindow.so.0.40

which isn't *that* much virtual address space; even Sun-2s support 16MB
of virtual address space per process.  The entire library is mapped in.

>Anyway, can anyone elaborate on a) how SunOs does shared libraries,

See above.

>b) how SysV does shared libraries

For System V Release 4, see above, with one change; instead of "crt0"
mapping in "ld.so", the ELF executable image header specifies that the
code to be run when the image is started is "ld.so", not the executable
image itself, and "ld.so" is handed a file descriptor that refers to the
executable image.  The intent behind this is to remove the requirement
that the executable image itself make any system calls directly, rather
than going through a shared library to do so, so that you can change the
way those calls are implemented and still have executable images work
(with modified "ld.so" and other shared libraries supplied with the
system).

For System V Release 3, libraries are assigned fixed locations in the
address space, so they aren't built with position-independent code and
no relocation is done; the entire library is mapped in (done by the
"exec" code at start-up time, not with "mmap", since there is no "mmap"
in S5R3 from AT&T).