Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.internals
Subject: Re: PIC and shared libraries (was Re: Fundamental defect of the concept of shared libraries)
Message-ID: <8057@auspex.auspex.com>
Date: 27 May 91 21:31:29 GMT
References: <224@titccy.cc.titech.ac.jp> <8029@auspex.auspex.com> <244@titccy.cc.titech.ac.jp>
Organization: Auspex Systems, Santa Clara
Lines: 44

>If the code must be strictly Position Independent, MIPS, HP-PA, RS/6000 and
>many other architectures can not support sharing of PIC, because of virtual
>address aliasing and inverted page tables. I am corrct here.

Would you please show some proof for your so-far-unsupported assertion
that you are correct when you say that architectures with virtual
address caches, or inverted page tables, cannot support having the same
physical page mapped to multiple different virtual addresses in
different processes?

I've indicated *several times* how that not only *can* be done, but how
it *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 (turn off caching
	in the rare case where that's not possible);

	if you get a cache miss, check whether the cache line actually
	has the same physical address as the virtual address
	that missed and, if so and the process has permission to access that
	virtual address, re-tag the cache line if it's tagged with virtual
	addresses (no need if the cache tags are physical addresses);

and how it is, as I remember, done on RS/6000s in the case of inverted
page tables:

	have a global virtual address space composed of a segment number
	and an offset-within-segment and a per-process virtual address
	space composed of a segment register number and an
	offset-within-segment;

	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;

	load up the segment registers on a per-process basis to give a
	segment with a given global virtual address different
	per-process virtual addresses in different processes;

but you haven't demonstrated why that doesn't work (probably because, as
proven by the existence of various Sun machines and IBM machines running
OSes that *do* support shared libraries that can be mapped to different
addresses, it's impossible to demonstrate that it doesn't work because
it *does* work!).