NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/os/linux/10559

Internet Message Format | 1992-09-12 | 1.6 KB

Path: sparky!uunet!spool.mu.edu!hri.com!snorkelwacker.mit.edu!bloom-picayune.mit.edu!daemon
From: [e-mail] (Peter MacDonald)
Newsgroups: comp.os.linux
Subject: re: shared libs
Message-ID: <[e-mail]>
Date: 12 Sep 92 17:13:16 GMT
Sender: [e-mail] (Mr Background)
Reply-To: [e-mail]
Organization: The Internet
Lines: 25

I wouldn't call shared libs under Linux unacceptable,  and it is
just plain incorrect to say that code is loaded at a fixed address.
Rather it is the jump table entry point that is loaded at a
fixed address.  The code can be moved to wherever you like.
However, there is one thing I wonder if we should not have done.

Currently, I believe that share lib jump tables are located just
before the shared lib code in the middle of user space.  Perhaps
ideally, the jump table should be located in high memory, just
above the stack.  Then the code could reside wherever you like.
of course, the sticky part is that the data would have to go
with  the jump tables, cause it can't be moved.  And it's size
is subject to change.

Personally, though, I don't believe there is any good reason
to change the current design.  And I don't believe the mythical
perfect "shared libs" implementation exists.  Does using PIC
generate Position Independant Data (PID) as well, or is there
a requirement for dynamic linking?  Dynamic linking carries
overhead that will make much less efficient that the Linux
scheme.

    - runtime overhead from the linking
    - larger images, because the symbol info is retained
    - shared text complications