Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!sdd.hp.com!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.internals
Subject: Re: Fundamental defect of the concept of shared libraries
Keywords: ISC i386 shared libraries
Message-ID: <1991May16.200702.7476@Think.COM>
Date: 16 May 91 20:07:02 GMT
References: <184@titccy.cc.titech.ac.jp> <1991May16.002617.15386@ladc.bull.com> <197@titccy.cc.titech.ac.jp>
Sender: news@Think.COM
Reply-To: barmar@think.com
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 34

In article <197@titccy.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes:
>To share libraries, they should be:
>	1) coded position independently (PIC)
>or
>	2) assigne static virtual address
>
>If we take 1), the hardware architecture must support PC relative jump,
>of course. Moreover, to access library private data, it must also
>address data PC relative. Aside from effeciency, not all architechture
>support this.

You don't *have* to have PC-relative jumps and data access, although it is
convenient.  The Multics compiler uses it when it can, but I think
PC-relative instructions have a relatively small limit on the offset.

When PC-relative addressing isn't available or usable, you just need
register+offset addressing, which most computers have.  On Multics, one of
the pointer registers by convention holds the address of the base of the
currently executing segment, and PIC simply offsets from this.  On a Unix
system, it would simply be a pointer to the location where the library is
mmap'ed.  The only tricky part is arranging for the register to be set
whenever an inter-module call or return takes place.

>Even worse, with some architechture, it is impossible to map several virtual
>addresses to a physical address. Virtually tagged cache and inverted
>page tables are notable examples.

Well, this kills any kind of shared text architecture, not just shared
libraries.
-- 
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar