🚀 go-pugleaf

In article <7952@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:
>> Far and away the simplest way is for the compiler to generate
>> Position Independent Code.  The libraries can then reside at
>> any place in the process' virtual address space.  They need not
>> be at the same place in all processes.
>
>Don't forget the problems of (a) where does static data for the library
>functions live (they need to know this), and (b) how does the user code
>find out where the foobar() function is.  I think the latter is more what
>the original question was about.
>-- 


Cripes, folks, you have been beating around the bush of dynamic
linking for weeks now. In the interest of calling a personal earth
moving device a spade, I'll sketch the mechanism. Now that Unix runs
on computers more like the power of its original parent, perhaps its
time for it to recapture some non-chewing-gum-and-bailing-wire system
technology from its own history.

one scheme works like this: 

Each object file is structured into four pieces:

    text
    definitions
    static
    linkage
    symbol

There has to be as storage allocation mechanism independent of
"running" a program.

Text references to external quantities are references through pointers
in the linkage. The initial copy of the linkage contains pointers that
take a fault when you reference through them. (your hardware does have
such minimal amenities, right? If not, put a trap instruction in the
linkage, and have the text jump there).

When the fault handler takes one of these linkage faults, it makes a
copy of the entire linkage section in per-process storage (on Unix you
may want it to be per-group-leader or something), and fixes the
faulting pointer to point to the linked-to library routine, using
naming information in the definitions section of both the referencer
and the referencee.  Once you have that, you are on the air with no
further faults.

Static lives in the static section. All references to static are
addressed as offsets from a pointer stored in a table.  When a file is
first linked to in a process, the static section is copied, and the
pointer initialized. Thus, each process gets its own static.

Manifestly, this is easier to do in a segmented environment than a flat
environment, but that shouldn't stop you for long.

Someone's comments about strcopy in shared memory are a red herring.
In systems with "shared memory", the vast bulk of the shared data is
pure code. As soon as you go to share something that is modifiable,
you are in the synchronization business. You use locks, semaphores, or
whatever you like. That's what shared data is all about. When I worked
on Multics, that's most of what I did was write shared memory
programs, and anyone out there working on Multiprocessor Unix is doing
the same thing.



Benson I. Margulies                         Kendall Square Research Corp.
harvard!ksr!benson			    All comments the responsibility
ksr!benson@harvard.harvard.edu		    of the author, if anyone.