Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mcnc!rti-sel!ge-rtp!ge-dab!steinmetz!davidsen
From: davidsen@steinmetz.UUCP
Newsgroups: comp.arch
Subject: Re: implementing shared libraries
Message-ID: <2513@steinmetz.steinmetz.UUCP>
Date: Tue, 21-Apr-87 11:34:54 EST
Article-I.D.: steinmet.2513
Posted: Tue Apr 21 11:34:54 1987
Date-Received: Thu, 23-Apr-87 02:54:10 EST
References: <12823@watnot.UUCP> <926@aw.sei.cmu.edu.sei.cmu.edu>
Reply-To: davidsen@kbsvax.steinmetz.UUCP (William E. Davidsen Jr)
Distribution: comp
Organization: General Electric CRD, Schenectady, NY
Lines: 48

In article <926@aw.sei.cmu.edu.sei.cmu.edu> firth@bd.sei.cmu.edu.UUCP (Robert Firth) writes:
>In article <12823@watnot.UUCP> ccplumb@watnot.UUCP (Colin Plumb) writes:
>>... about Amiga shared libraries ...
>
>Far and away the simplest way is for the compiler to generate
>Position Independent Code.  The libraries can then reside at
>any place in the process' virtual address space.  They need not
>be at the same place in all processes.

Position independent code  as I have seen it is really "IC relative"
code, performing operations relative to the current instruction pointer
rather than using an address. This presents some problems with a shared
library, since the location depends on the size of the program and/or
library. This can be overcome by reserving a portion of the address
space for the system routines, but I'm looking for more information on
doing things PIC and allowing linking.

Several approaches have been taken. NatSemi has some products with the
system services located in a fixed place at the bottom of memory (sorry,
it's been awhile) and what is there is a jump table. This allows the
program and library to be anywhere, but the jump table is fixed.

Some systems do it with a hardware jump table accessed by INT
instructions which store the IC and transfer to a known location. The
old GE600 series had three ways to create a fault, being MME (master
mode entry), DRL (derail), and fault tag operator. The last was an
address modifier rather than an opcode, and "just happened" to be the
modifier used in an ASCII data descriptor. This allowed the descriptor
to be "executed" causing the falut tag before the instruction was
decoded, and allowing the o/s to fetch the data pointer and output to
the terminal. Yecch! Intel 80x86 chips use this "fault vector"
approach, and it makes the code quite compact.

Other systems put the library routines in known segments, again Intel
hardware among others, and this provides about the same effect as using
the pagining in a VAX to simulate putting the library at a know
location.

  One prototype package using SysV shared memory uses 'shmget' to fetch
the location of a set of shared libraries and services (a pointer
vector). Any system using a pointer vector allows the library to be
changed while the system is running, by changing the vector values. I'm
not sure how useful this is, just mentioning it.
-- 
bill davidsen			sixhub \
      ihnp4!seismo!rochester!steinmetz ->  crdos1!davidsen
				chinet /
ARPA: davidsen%crdos1.uucp@ge-crd.ARPA (or davidsen@ge-crd.ARPA)