NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/unix/bsd/5532

Text File | 1992-09-11 | 3.8 KB | 78 lines

Newsgroups: comp.unix.bsd
Path: sparky!uunet!cs.utexas.edu!uwm.edu!caen!hellgate.utah.edu!fcom.cc.utah.edu!cs.weber.edu!terry
From: [e-mail] (A Wizard of Earth C)
Subject: Shared Libraries for 386BSD
Message-ID: <[e-mail]>
Keywords: shared libraries X X11
Sender: [e-mail]
Organization: Weber State University  (Ogden, UT)
References: <[e-mail]> <veit.716107923@du9ds3> <[e-mail]>
Date: Fri, 11 Sep 92 15:49:12 GMT
Lines: 65

In article <[e-mail]> [e-mail] (Gary A Browning) writes:
>I just finished installing X and noticed that most binaries are several times
>larger than expected due to the lack of shared libraries.  I caught an article
>posted here a few days back that quickly described the SysVr3 approach of using
>fixed addresses for the libraries and the Sun/SysVr4 approach of using position
>independent code.
>
>I tend to dislike the SysVr3 method since I got the impression that the source
>code had to be written differently (though I am not sure why).  I also noted
>that the GCC-2.2.2 compiler I just got compiled can produce PIC code which
>would be one of the major hurdles for the SysVr4 method.
>
>Any knowledgable person want to talk a little more about the pros and cons of
>these two (or any other) approach?

    Position independant code has a lot to recommend it, not the least
of which is the ability to page the code in and out in pagesize hunks, and
the ability map these pages, individually, into the end of the processes
address space for the duration of their use (you would probably want to
have room for two pages to take into account looping of execution across one
page boundry).

    Fixed code can have the same thing done, but this usually involves
swapping the library pages for low-core process pages (as opposed to the
3B1 method of locating the library at a known location, where the "stub"
call routines actually do the calling by known address offset and each
library is loaded to a fixed memory location above the "reasonable" size
of a user process).

    VMS does it using an image, where a process may map sections of the
image into it's own address space.  This was a compromise for persistant
object mapping without a great deal of change to the OS itself.

    I personally vote for the PIC approach, since it seems to restrict
the size of my programs less, and generally will not result in swapping
out perfectly good real code in my program while there is space left at
the end of my address range.

    The main problem with PIC is the nature of some of the errors
in code generation with gcc 2.2.2, problems dealing with the code in
gas (which still needs a lot of work to make PIC binaries), and the
linker and kernel work necessary to link against "nonexistant" libraries
and demand page a file other than our executable into our address space
and execute it.  The other big win, that of loadable kernel modules, is
actually achievable with the compiler that came with 386bsd, and doesn't
PIC or gcc 2.2.2.

>What ever happened to the Jolix's special interest groups?  Wasn't one of them
>addressing the shared library problem?

    I haven't heard of anything like this, except the sideways reference
in Lynne's posting of a preferred newsgroup list.


                    Terry Lambert
                    [e-mail]
                    [e-mail]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
--
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------