Shared libraries

[amolitor at eagle.wesleyan.edu]

In article <5152f9e6.20b6d at apollo.HP.COM>,
	goykhman_a at apollo.HP.COM (Alex Goykhman) writes:
> 
> Come one, guys.  There is nothing special about a shared library.  Think
> of it as a part of, or an extention to, the kernel.  A s.l. is just file
> with a bunch of entry points.  All you need to do is to map it somewhere
> in the virtual address space,  and trap every call to the s.l. entry
> points, and substitute it with a call to the corresponding routine.
> 
> Mapping is trivial, trapping is machine-dependent, and you can't change it
> anyway, so it must take a lot of imagination to produce an implementation
> of shared libraries that would not be simple and elegant.
> 

	Well, it depends on what you mean by 'trivial'. As has been pointed
out, there is a problem with static data required by library routines, and
the solution to this is to use a paging system providing copy-on-write. I
would hesitate to refer to load time linking as 'trivial', as well. And
yeah, I have written a (simple) load-time linker. Doing it right is hard.

	I've not noticed anyone mention the VMS implementation. It's my
impression that the VMS shared libarary system is Done Right. Based on
vague memories of a single dark night years ago spent RTFMing and peering
at the output from analysis tools, I believe that VMS a) uses the
copy-on-write abilities of it's memory system to deal with static data
areas gracefully and b) has proper load-time linking to libraries -- i.e.
calls to library routines are exactly the same as any other call. There is,
therefore, no performance hit besides the startup (both in linkage, and in
copying on write of data areas). This is typically more than made up for by
the performance GAIN achieved by not loading 100K of library routines when
you execute the image. To be precise, I am happier running code linked to
sharable libraries than statically linked.

	Andrew

> | Alex Goykhman