Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!helios!mtecv2!msi.umn.edu!news.cs.indiana.edu!mips!swrinde!zaphod.mps.ohio-state.edu!wuarchive!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.internals
Subject: Re: Fundamental defect of the concept of shared libraries
Keywords: ISC i386 shared libraries
Message-ID: <8144@auspex.auspex.com>
Date: 31 May 91 21:54:03 GMT
References: <8054@auspex.auspex.com> <8057@auspex.auspex.com> <265@titccy.cc.titech.ac.jp>
Organization: Auspex Systems, Santa Clara
Lines: 60

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

I agree that if the compiler doesn't treat "strcmp()" specially - e.g.,
by having a header define "strcmp(a, b)" as "_builtin_strcmp(a, b)", and
generating, say, code for a call to "_builtin_strcmp(a, b)" that
compares the first two characters of "a" and "b" and, only if they're
not equal, calling the "strcmp()" routine starting at one character into
the strings - the compiler can't automatically in-line code in
"strcmp()".

However, the "STRCMP()" *macro* that appears in B news will work just fine
with a "strcmp()" in a shared library.  You cited B news as an
example of a place where inlining is a win; that particular example
doesn't require unshared libraries to get that win.

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

I take it you're finally agreeing that a given physical page can be
mapped into different virtual addresses in different processes, even if
you have a virtually-addressed cache or inverted page tables?

There are two separate issues here, which you're mixing together:

1) the issue of code that will run regardless of what its virtual
   address is, and that doesn't have to be modified to run at a
   different address;

2) the issue of mapping the same physical page into different virtual
   addresses within different processes.

The first issue is what *I* consider the issue of position-independent
code; it's already been demonstrated that all the major 32-bit
microprocessor architectures can handle that, as can various other
32-bit architectures such as System/3[679]0, VAX, etc..

The second issue is the issue of cache aliasing; in order to effectively
*use* position-independent code on a system with virtual addressing and
a cache that's not purely physically addressed, you have to be able to
deal with cache aliasing.  Making sure that all the virtual addresses
are the same modulo the cache size solves the problem on a lot of caches
(Sun, Cypress 7C60[45], MIPS R4000, among others); the caches with
virtual, rather than physical, tags also have to do some alias checking.

I.e., virtual indexing of caches, and even virtual *tagging* of caches,
isn't a barrier to using position-independent code.

The same is true of systems such as the RS/6000 with inverted page
tables; the RS/6000's scheme handles that.

No, you can't put the shareable object at arbitrary locations in the
address spaces of the processes and leave them cacheable in a
virtually-indexed cache.  Nobody was saying that you could, and I
sincerely *hope* nobody was claiming that the fact that you couldn't was
at *all* a major obstacle to implementing position-independent shareable
code objects!