Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!uunet!kddlab!cs.titech!titccy.cc.titech!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.unix.internals
Subject: PIC and shared libraries (was Re: Fundamental defect of the concept of shared libraries)
Message-ID: <244@titccy.cc.titech.ac.jp>
Date: 27 May 91 09:13:45 GMT
References: <1991May20.163317.19968@decuac.dec.com> <1991May20.175555.13943@batcomputer.tn.cornell.edu> <224@titccy.cc.titech.ac.jp> <8029@auspex.auspex.com>
Sender: news@titccy.cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 25

Sorry for my misunderstanding about PIC and shared libraries.

In article <8029@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:

>>As I already said, PIC (Position Independent Code) imposes several
>>restrictions to hardware, which many architectures can't obey.
>
>Which architectures?

If the code must be strictly Position Independent, MIPS, HP-PA, RS/6000 and
many other architectures can not support sharing of PIC, because of virtual
address aliasing and inverted page tables. I am corrct here.

The problem is that, to support shared libraries, strict PIC is not required.

Instead, it is required that the same code runs if the relocation is
multiple of some constant. To support many libraries at once, the
constant should be small enough compared to the size of address
space.  For example, with most segmented architectures, Segment number
Independent Code is enough, though extra overhead to reload segment
registers costs for inter-object-module call.

So, the remaining problem is the performance.

							Masataka Ohta