Article View: comp.arch
Article #13472Re: implementing shared libraries
From: firth
Date: Thu, 23 Apr 1987 14:13
Date: Thu, 23 Apr 1987 14:13
39 lines
2828 bytes
2828 bytes
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.
Technical Details
Message-ID:
<1110@aw.sei.cmu.edu>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!rutgers!seismo!rochester!pt.cs.cmu.edu!sei!sei.cmu.edu!firthReferences:
<12823@watnot.UUCP> <926@aw.sei.cmu.edu.sei.cmu.edu> <7952@utzoo.UUCP>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!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