Fundamental defect of the concept of shared libraries

[Frank Mayhar]

In article <197 at titccy.cc.titech.ac.jp>, mohta at necom830.cc.titech.ac.jp (Masataka Ohta) writes:
-> In article <1991May16.002617.15386 at ladc.bull.com> I write:
-> >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 _you_ start including "facts" in your postings, then.  So far all
I've seen is supposition and unsupported assertions.

-> Effeciency is only one aspect of the problem.

Not true.  Regardless of the complexity of the implementation, the only
real tradeoff is between efficiency and utility.  See my previous posts
regarding this.

-> To share libraries, they should be:
-> 	1) coded position independently (PIC)
-> or
-> 	2) assigne static virtual address

Granted, more or less.

-> 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.

Not necessarily.  While it may well need PC-relative transfers, data addressing
may use an different mechanism (probably also register-relative, but almost
certainly not PC-relative).

-> Aside from effeciency, not all architechture support this.

Examples?  Certainly the 680x0 and the 80x86 support this, as well as most
mainframe architectures.  I expect that almost any architecture would support
this.  I mean, what's the difference between PC-relative addressing and any
other kind of register-relative addressing?  And, as has already been stated,
PC-relative jumps aren't essential; other forms of indirect transfers work
as well.

-> Note that, library private data is inevitable to support calls between
-> libraries, position independently.

Not inevitable.  It depends on the implementation; I can certainly imagine
an implementation that supports inter-library calls via use of automatic
storage ("stack" space).  While technically this is "library private data,"
it doesn't have the implementation complexities that static storage does.

-> 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.

Perhaps these architectures aren't suitable for shared libraries.  And, as
Barry Margolin said, if this is the case, _any_ kind of text sharing is
dead.  IMHO, though, the concept of virtual memory implies the ability to
map a physical address to several virtual addresses.  Show me one that doesn't
allow this, and I'll show you one that is almost useless for modern computing
purposes. 

-> 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.

How is 32 bits "obviously" not enough?  Four gigabytes of address space isn't
enough?  How big _are_ your programs, anyway?  I agree that solving such
problems are nontrivial, but that doesn't mean that they aren't worthwhile.

-> Moreover, compatible libraries must have the same address, whose scheme
-> will be very complex, even though it exists.

I don't understand this.  Your English is somewhat mangled.  Care to explain?

-> 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.

Why not?  Seems to me that it would depend on the context of the call:  if
the call is happening in the first program, the call would be to B.0; if
in the second, the call would be to B.1.  Regardless, this is an implementation
issue.  Likely nontrivial, but solvable.

-> 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.

The above scheme would avoid this problem.

-> I hope you can now understand how complex the shared library is.

Oh, I quite understand that shared library _implementations_ are complex.
I hope that you can now understand that shared libraries are often _useful_,
regardless of the complexity of the implementation.

-> The fundamental solution is, of course, not to have shared libraries.

The fundamental solution is, of course, not to engage in pointless religious
arguments with dogmatic individuals who are closed to any ideas not their own.
-- 
Frank Mayhar  fmayhar at hermes.ladc.bull.com (..!{uunet,hacgate}!ladcgw!fmayhar)
              Bull HN Information Systems Inc.  Los Angeles Development Center
              5250 W. Century Blvd., LA, CA  90045    Phone:  (213) 216-6241