Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!apollo!goykhman_a
From: goykhman_a@apollo.HP.COM (Alex Goykhman)
Newsgroups: comp.unix.internals
Subject: Re: Shared libraries
Message-ID: <51590fb2.dd5f@apollo.HP.COM>
Date: 3 May 91 21:05:00 GMT
Organization: Apollo Computer, Chelmsford, Mass.
Lines: 34

In article <1991May2.172740.11422@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
>In article <5152f9e6.20b6d@apollo.HP.COM> goykhman_a@apollo.HP.COM (Alex Goykhman) writes:
>>
>>Come one, guys.  There is nothing special about a shared library.  Think
>>of it as a part of, or an extention to, the kernel.  A s.l. is just file
>>with a bunch of entry points.  All you need to do is to map it somewhere
>>in the virtual address space,  and trap every call to the s.l. entry
>>points, and substitute it with a call to the corresponding routine.
>
>  Unfortunately it is not that simple.  The trouble is that the text segment
>of the module contains references to the data and bss, which will be different
>for each use of the shared routines.
>
>  The proper way to do this is to design the shared library so that all modules
>in it have only text segments, and zero-length bss and data segments.  This
>requires a substantial change in coding style, although one which is also
>worthwhile for better handling of multiple processors which also require
>better reentrancy.  Essentially it requires a redesign of C.  Not really a
>redesign of the language, but a redesign of the implementation.

    I agree, but the transition from one design style to another is not nearly
    as difficult as you just described.  A few years ago I had a task of converting a 
    dozen or so C routines to a shared library format.   All I had to do was to 
    replace the static variables with their dynamic equivalents, which I accomplished 
    by moving a few dozen lines of code around using my favorite editor.  Our C compiler
    allocated the dynamic variables on the current process' stack, thus making 
    the routines both re-entrant, and suitable for multi-processing.  BTW, I can't
    think of a single s.l.-specific issue introduced by multi-processing.  

>-- 
>=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=
>  Neil W. Rickert, Computer Science               <rickert@cs.niu.edu>
>  Northern Illinois Univ.
>  DeKalb, IL 60115                                   +1-815-753-6940