Fundamental defect of the concept of shared libraries
Barry Margolin
barmar at think.com
Fri May 17 06:07:02 AEST 1991
In article <197 at titccy.cc.titech.ac.jp> mohta at 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 at think.com
{uunet,harvard}!think!barmar
More information about the Comp.unix.internals
mailing list