Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!uunet!kddlab!cs.titech!titccy.cc.titech!necom830!mohta
From: mohta@necom830.cc.titech.ac.jp (Masataka Ohta)
Newsgroups: comp.unix.internals
Subject: Re: Fundamental defect of the concept of shared libraries
Keywords: ISC i386 shared libraries
Message-ID: <265@titccy.cc.titech.ac.jp>
Date: 30 May 91 12:55:47 GMT
References: <8054@auspex.auspex.com> <8057@auspex.auspex.com>
Sender: news@titccy.cc.titech.ac.jp
Organization: Tokyo Institute of Technology
Lines: 46

In article <8054@auspex.auspex.com>
	guy@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@auspex.auspex.com>
	guy@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@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