Pyramid Support of Shared Libraries

[Eric Bergan]

In article <17350 at bellcore.bellcore.com> gregg at dduck.UUCP (Victor Scott Gregg) writes:
>In article <79957 at pyramid.pyramid.com> 
>csg at pyramid.pyramid.com (Carl S. Gutekunst) writes:
>
>>Implementing shared libraries would mean changing binary file
>>formats, something that was a more-pain-that-gain proposition. 
>
>Implementing shared-libraries would add a new binary format, but there 
>is no reason that existing binaries could not be supported.

	A new binary format has far reaching implications, however, since
it then causes changes to the compilers, loader, ar, debuggers, etc.

	We had originally intended to implement System VR3-style shared
libraries. But then SVR4 came out and completely changed (again) how shared
libraries are to be handled. As we move to support SVR4, we will be
supporting SVR4-style shared libraries, and making the necessary changes
to the support tools.

>Once shared libraries are available, it would be possible to make fixes 
>to standard libraries without touching the application binaries. This is one 
>of two main benefits of shared libraries.

	In fact, it also extends to system calls, since they are can
then be handled by a shared library, and relinking the world is not necessary.
We will be doing and supporting this with SVR4 support.

>The other is to reduce the memory and paging requirements for application 
>transactions which use common code.  This seems like a WIN in the MISserver.

	It should be noted that there is one loss with shared libraries:
all references to external symbols end up going through an extra level
of indirection. Depending on architecture, this can add several instructions
to a variable reference, plus an additional memory reference which may or
may not be in the data cache. It is yet to be determined what the performance
penalty for this is.

-- 

					eric
					...!pyramid!eric