Fundamental defect of the concept of shared libraries
Masataka Ohta
mohta at necom830.cc.titech.ac.jp
Thu May 16 17:07:24 AEST 1991
In article <1991May16.002617.15386 at ladc.bull.com>
fmayhar at hermes.ladc.bull.com writes:
>There may actually not be any "right" implementations extant at the
>moment (this is debatable), but that's not the point.
Without any fact, your claim is nothing.
Let's see what's wrong with shared libraries.
>-> Indirect jumps and accompanied process private data for the jump table.
>
>So what would be a better way to do it?
>
>Really, there's a tradeoff between the utility of shared libraries and
>efficiency.
Effeciency is only one aspect of the problem.
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.
Note that, library private data is inevitable to support calls between
libraries, position independently.
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.
If we take 2), even if you have enough address space to map all libraries
(32 bits is obviously not enough, I even think 48 bits is not), it will
be nightmare to maintain consictency. Different libraries must
have different addresses, of course, which is already non-trivial.
Moreover, compatible libraries must have the same address, whose scheme
will be very complex, even though it exists.
Even worse, if a program is linked with libraries A.0 and B.0 and the
other program is linked with libraries A.0 and B.1 (an upgraded version
of B.0) and a function in A.0 calls a funtion in B.*, it can't. As
a workaround, we can have two versoins of A.0: A.0.B.0 and A.0.B.1.
Thus, with the increase of number of kind of libraries, the number of
libraries and required storage grows exponentially.
I hope you can now understand how complex the shared library is.
The fundamental solution is, of course, not to have shared libraries.
Masataka Ohta
More information about the Comp.unix.internals
mailing list