Xref: utzoo comp.unix.wizards:10998 comp.os.misc:507
Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.unix.wizards,comp.os.misc
Subject: Re: tracing system calls
Keywords: truss syscall & trace
Message-ID: <67440@sun.uucp>
Date: 8 Sep 88 17:14:17 GMT
References: <21606@ccicpg.UUCP> <7622@boring.cwi.nl> <2040@cuuxb.ATT.COM> <7716@bigtex.uucp>
Sender: news@sun.uucp
Lines: 34

> How does this implementation compare to the SysVr3 shared libraries?
> I had been under the impression there that shared libraries were
> mapped into the address space by the kernel, not by the user process.
> Is there any particular advantage between the two schemes, or does
> SysVr3 do it like Sun OS-4?

S5R3 does it in the kernel.  SunOS 4.0 does it in user mode.  The advantage to
the latter is that it's done in user mode; this means the code that does it
isn't wired-down code in the kernel, and means that it's easier to debug,
replace, etc..

It also means it's easier to make it more powerful; the SunOS shared libraries
are not tied to specific locations, and relocation is done when the library is
mapped in.  Process A can map the library in at address A, while process B can
map it in at address B.  This obviates the need to "register" shared libraries
at particular addresses.

In addition, you can specify a "search path" for shared libraries, so that you
can provide a "private" shared library that, for example, could wrap all system
calls that take pathnames with code that knows how to expand "~username", so
that all dynamically-linked programs will understand "~username" (with one
exception; set-UID and set-GID programs ignore this path, for obvious reasons).
Not all of the mechanism to make this convenient is present in the current
release, but it will probably appear in future releases.

You could also provide a run-time interface to the dynamic linker, so you can
write code that, for example, reads the name of a shared library file from
another file, and then gets a pointer to the routine named "foobar" in that
file and calls it.  This could be convenient for structured document editors;
if you wanted to define a new kind of frame within a document, say a frame for
editing PERT charts, you could make the implementation of that frame into a
shared library file and tell the editor that the code to implement this kind of
frame is in "/usr/local/docedit/lib/pert_frame.so".  Again, this mechanism is
not currently present, but will probably appear eventually.