Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/17/84 chuqui version 1.9 3/12/85; site unisoft.UUCP
Path: utzoo!linus!philabs!prls!amdimage!amdcad!amd!vecpyr!lll-crg!dual!unisoft!pc
From: pc@unisoft.UUCP (n)
Newsgroups: net.arch,net.unix-wizards
Subject: Re: Shared runtime libraries - SV shared memory?
Message-ID: <457@unisoft.UUCP>
Date: Tue, 14-May-85 11:29:27 EDT
Article-I.D.: unisoft.457
Posted: Tue May 14 11:29:27 1985
Date-Received: Fri, 17-May-85 04:15:57 EDT
References: <388@rtech.ARPA>
Distribution: net
Organization: UniSoft Systems, Berkeley
Lines: 21
Xref: linus net.arch:1010 net.unix-wizards:10396

<munch>
	The way to do solve these problems are very much the same as VMS does it

	1.	Provide kernel support for mapping in the shared library (which 
		is after all just another sort of shared text, mapped at a
		different address, why not generalise this?) at exec time.

	2.	Make all the entry points into the library through a set of
		jump vectors (this way the entry point is always the same on
		many different versions of the library). This can be done by
		the same program that makes a stripped down library for linking.

	3.	Library data ... ugh ... the hard part, either rewrite the 
		routines so that they don't use it (the easy way out,
		unfortunatly there are many that already do this ... ie stdio)
		or provide a separate, copy-on-reference segment, also at a
		known address to store the data in.



			Paul Campbell		..!ucbvax!unisoft!paul