Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!elroy.jpl.nasa.gov!ncar!midway!msuinfo!rang
From: rang@cs.wisc.edu (Anton Rang)
Newsgroups: comp.unix.internals
Subject: Re: Shared Lib Question (ISC)
Message-ID: <RANG.91May15231758@nexus.cs.wisc.edu>
Date: 16 May 91 05:17:58 GMT
References: <184@titccy.cc.titech.ac.jp> <19273@rpp386.cactus.org>
	<187@titccy.cc.titech.ac.jp> <1991May15.043318.7046@mp.cs.niu.edu>
	<194@titccy.cc.titech.ac.jp>
Sender: news@msuinfo.cl.msu.edu
Organization: UW-Madison CS department
Lines: 49
In-Reply-To: mohta@necom830.cc.titech.ac.jp's message of 15 May 91 07:15:19 GMT

In article <194@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>By now, I have claimed there can be no right implementation of shared
>libraries because of the complexity related to the indirect jump table.

  I'm not sure what the big deal about an indirect jump table is,
honestly.  Are you just complaining that it's slower?  If most of the
time a program is running is spent in loops, I'd hope that the
compiler would keep function addresses in registers, anyway (though of
course there are never enough registers).  If that's not your
complaint, then what's the problem with having a jump table?

  Anyway....

  You don't need an indirect jump table if your shared libraries link
at a static location (messy and not general), or if you're willing to
do load-time fixups on your code (expensive), or if you have an
architecture which supports segmentation.

  VMS allows you to build shared libraries which load at a fixed
location, and does not use indirect jumps in this case.  This is
rarely used, since it requires that shared libraries built in this
manner not conflict with each other (in terms of address space) and
must load at a high enough address to leave space for the user image.

  I don't know of any operating systems which support multiple
processes which use the load-time fixup approach.  Certain micro
systems (e.g. the Apple //gs) do this, but the cost on a multi-user
machine of not being able to share pages (and of paging everything in
as you do the load-time fixup) is high.

  You could do run-time fixup if you were willing to write to your
code pages, by making 'call XXXX' into a trap instruction and setting
the real address up the first time that call was hit.  I don't think
this would be worth it for many real applications.

  I'm not familiar enough with OSes running on segmented architectures
to be sure if there are any that use this approach, but I seem to
recall that MULTICS did, and that the cost to call a shared library
routine was higher on the *first* call from a particular point but
that the code was then patched to jump directly to the routine.
(Which presumably defeated code sharing?  I'll shut up now because I'm
not really sure and can't find my MULTICS papers.)

  The benefits of shared libraries, both in saving space on disk and
in sharing code in memory, seem to me to outweigh the benefits.  I
haven't seen any empirical studies of this yet, though.  I'm sure they
exist, somewhere.

	Anton
   
+---------------------------+------------------+-------------+----------------+
| Anton Rang (grad student) | rang@cs.wisc.edu | UW--Madison | "VMS Forever!" |
+---------------------------+------------------+-------------+----------------+