Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!firth
From: firth@sei.cmu.edu.UUCP
Newsgroups: comp.arch
Subject: Re: implementing shared libraries
Message-ID: <1110@aw.sei.cmu.edu>
Date: Thu, 23-Apr-87 09:13:35 EST
Article-I.D.: aw.1110
Posted: Thu Apr 23 09:13:35 1987
Date-Received: Sat, 25-Apr-87 04:28:23 EST
References: <12823@watnot.UUCP> <926@aw.sei.cmu.edu.sei.cmu.edu> <7952@utzoo.UUCP>
Sender: netnews@sei.cmu.edu
Reply-To: firth@bd.sei.cmu.edu.UUCP (PUT YOUR NAME HERE)
Organization: Carnegie-Mellon University, SEI, Pgh, Pa
Lines: 39

More on PIC, mainly in reply to Henry Spencer

(a) the code of the shared libraries is position independent.

(b) all read-only data needed by eg arctan is kept inline with
    the code (alternating code Psects and data RO Psects). Yes,
    you probably need a PC-relative data access mode.

(c) any read-write data space is supplied by the calling process,
    either as an extra parameter of every relevant call, or by
    convention via a specific general register.  The former is
    cleaner, but for things like RANDOM the latter is usually
    preferred.  The way I've seen it, the Assembler macro that
    generates the library EXTERNAL directives also creates
    the necessary chunks of library Dsect.  Only works for ONE
    library at a time, of course.

(d) you can get at the routines in two ways.  If you have static
    linking, then the linker decides for each process where in its
    virtual address the library will live, and resolves references
    to it accordingly.  It leaves a cue directive in the process
    image, and the loader points the proper piece of virtual address
    at the physical address where the library is resident.  This
    costs nothing at run time, but means you must relink your
    process to move the virtual position of the library.  Of course,
    moving the physical code of the library damages nothing, as
    long as you fix the address translation tables of the processes
    pointing at it.

(e) If you want to be fully dynamic, then you need a jump table.  In
    principle, you have one table in each process, containing one entry
    for each library routine, and the OS changes the table entries
    whenever the library is moved.  Using another level of indirection,
    the process can have one entry per library, pointing to the start
    of a relative jump table in that library, containing one entry per
    routine.  If you do not have memory management but need to do a
    lot of multiprogramming, this is perhaps the least messy way.  You
    can move the library code around to compact free memory, as long
    as you change the pointers in every process.