Fundamental defect of the concept of shared libraries

[Masataka Ohta]

In article <8054 at auspex.auspex.com>
	guy at auspex.auspex.com (Guy Harris) writes:

>>STRCMP() is source code level inlining of strcmp(), *NOT* strcmp()
>>in a shared library.

>Yes, that's exactly what I said!  It's source-code-level inlining, which
>works JUST FINE with "strcmp()" in a shared library.

No. You said:

>"In-lining of functions in shared libraries" is, of course, *NOT*
>"impossible", as demonstrated by that.

while I said:

:In-lining of functions in shared libraries is, of course, impossible.

As you agree now, strcmp() in a shared library is not in-lined.

In article <8057 at auspex.auspex.com>
	guy at auspex.auspex.com (Guy Harris) writes:

>I've indicated *several times* how that not only *can* be done, but how
>t *is* done on Suns, in the case of virtual address caches:
>
>	ensure that all the virtual addresses get mapped to the same
>	cache line by aligning the mappings properly

See <244 at titccy.cc.titech.ac.jp>:

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

In this case, cache size can be the constant.

>	have the virtual addresses in the inverted page table be
>	addresses in the *global* virtual address space, because a given
>	page has only one virtual address in *that* space;

In this case, segment size of the global virtual address space can be the
constant.

							Masataka Ohta