Fundamental defect of the concept of shared libraries

[Masataka Ohta]

In article <1991May16.200702.7476 at Think.COM> barmar at think.com writes:

>>	1) coded position independently (PIC)

>You don't *have* to have PC-relative jumps and data access, although it is
>convenient.

No, I don't have to, but it is very inconvenient not to do so.

>When PC-relative addressing isn't available or usable, you just need
>register+offset addressing, which most computers have.

I was wrong here, yes, it is possible if we use indirect addressing to
access global data, but it is slow.

>The only tricky part is arranging for the register to be set
>whenever an inter-module call or return takes place.

The call overhead is six extra cycles with typical RISCs, whenever an
inter-object-file (not inter-library) call-return takes place. It is
not negligible when we are heavyly doing something like strcmp().

As I re-read the discussion, someone mentioned the possibility of speed
up by globally optimizing compiler.  But, that is unfair. With the same
amount of optimizaiton, statically linked libraries can have better
optimization such as in-lining. You may remember that the speed of Bnews
was actually improved by in-lining the first part of strcmp(). In-lining
of functions in shared libraries is, of course, impossible.

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

You can always share text as usual UNIX box do, because it only requires
to map a single virtual address of several different processes to a
         ^^^^^^                            ^^^^^^^^^^^^^^^^^^^
physical address.

							Masataka Ohta