Fundamental defect of the concept of shared libraries

Guy Harris guy at auspex.auspex.com
Fri May 24 04:13:27 AEST 1991


>>Are there any architectures of interest in this discussion that can't
>>support PC-relative references?
>
>R3000.

Well, the R-series branch instructions are PC-relative.  The "jump"
instructions aren't, but unless you have to branch more than 32767 bytes
in either direction, you can use the branch instructions.

I'd also assumed that by "PC-relative" you included references relative
to, say, the PC of the beginning of the routine; you obviously don't
need to have *all* references be relative to the PC of the referencing
instruction.  The PC can be loaded into a register by doing a BGEZAL
with the register being tested being r0.  This involves some shuffling
of registers, but I think MIPS's compiler can deal with that....

>>If you believe that a system with a virtual-address cache, or a system
>>with inverted page tables, cannot map several virtual addresses to a
>>physical address, you're wrong.
>
>I am correct. It can't map them.

You're completely incorrect, because those systems can map them.

"Virtual Address Cache in UNIX", in the summer 1987 USENIX proceedings,
discusses how Sun does it with their virtual address cache.  The cache
will do alias checking if the different virtual addresses map to the
same cache line; the OS tries to align the virtual addresses (and
generally succeeds) so that the different virtual addresses will so map.

IBM does it with their inverted page table by, as I remember, giving the
page one virtual address within a large (>32 bit) virtual address space,
and then loading segment registers up in different processes to point to
the same virtual address; they can load different segment registers, so
that different second-level 32-bit virtual addresses refer to the same
first-level virtual address.  The "IBM RISC System/6000 Technology"
collection of papers should get you started on reading how they do it.

Now, go read those papers, and then either explain why those papers
don't tell the truth, or admit that you are NOT correct.



More information about the Comp.unix.internals mailing list