Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!mp.cs.niu.edu!rickert
From: rickert@mp.cs.niu.edu (Neil Rickert)
Newsgroups: comp.unix.internals
Subject: Re: Shared libraries
Message-ID: <1991May2.172740.11422@mp.cs.niu.edu>
Date: 2 May 91 17:27:40 GMT
References: <5152f9e6.20b6d@apollo.HP.COM>
Organization: Northern Illinois University
Lines: 24

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.

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