Date: Mon, 25 Sep 1995 10:13:56 +0000 From: Matt Thomas <matt@lkg.dec.com> To: hackers@freefall.freebsd.org Subject: Re: Big win for BSD/OS compatibility Message-ID: <199509251014.KAA06744@whydos.lkg.dec.com> In-Reply-To: Your message of "Sun, 24 Sep 1995 17:17:30 -0400." <Pine.BSF.3.91.950924171648.4383A-100000@aries.ai.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan Hubbard said:
> I'm currently talking with them (Netscape) about this very subject.
> Apparently they need dlopen()/dlsym() functionality in Netscape 2.0
> and this is not provided in BSDI 1.1, so there's a problem.
>
> I'm now busily trying to talk them into doing both BSDI 2.0 and
> FreeBSD 2.x native ports.. :-)
However BSD/OS 2.0 doesn't have dlopen or dlsym either. From the 2.0
slicc man page:
BUGS
Shlicc is currently a shell script, with all the problems that entail
from that. Pure compiles aren't too much slower because the script execs
cc(1) as soon as it parses enough arguments to realize that linking isn't
necessary. Linking ought to be slower because the script runs awk(1) and
other heavyweight programs, but the fact that no code needs to be loaded
from the stub library, and hence no relocations need to be performed on
the library or its symbols, can actually make linking a little faster.
If a shared library is missing or corrupted or unreadable, programs will
print errors and dump core. The shared C library contains the library
loader routine; if it's hosed, then basically nothing works. If the
shared C library is deleted or mangled, you may need to boot from floppy
to restore it.
Turning on profiling turns off shared libraries. It didn't seem useful
to save space in binaries and then waste it by producing profiled shared
libraries that are hardly ever used.
Shared library text and data do not appear in core dumps. The current
core dump file format isn't rich enough to support multi-segment core im-
ages. Also, debugging can be inconvenient because you can't put break-
points in code that isn't mapped yet, and the libraries are not mapped
until after the program starts.
The overhead of loading the shared libraries is small but measurable.
There are 6 system calls per library at startup before executing any user
code. There is also some small overhead in indirecting through the jump
table. On the plus side, sharing library pages means that they are more
likely to be in core and thus less likely to require paging in.
The current implementation is cheap and fast, using statically linked li-
braries rather than dynamically linked libraries. This scheme makes bi-
naries smaller and start-up much faster, but it has some limitations. In
particular, if you write a substitute for a library routine and use the
shared library, the calls to that routine from within the shared library
will use the library version, not your version. This is particularly an-
noying with programs that provide their own malloc(3) and free(3) rou-
tines; if you try to free memory that was generated from (say) the shared
strdup(3), your program can dump core. Also, if library code compares a
pointer to a library function that was passed to it from user code to the
address of the library function, it will fail because the user code sees
only the address of the jump table slot. (Yes, some standard library
code actually does this!)
The current implementation has no automatic versioning. Crude library
version changes can be effected using the shlib.map file, however.
In spite of the names and the implementation strategy, these shared li-
braries have nothing in common with SVr3 shared libraries and are not
compatible with them. You aren't imagining things, though; this imple-
mentation is just as simple and lacking in features. Simpler, actually:
there is no special kernel support for these shared libraries; they are
implemented in user mode with standard BSD system calls.
While this may be fine for BSDI to base their product, there is no way of
any third party product (such as Netscape) to produce their own shared
libraries. All libraries have base addresses and there is not a guarunteed
way of avoiding address conflicts.
The FreeBSD (and NetBSD for that matter) dynamic libraries is much more
sophisticated than what's in BSD/OS 2.0.
Matt Thomas Internet: matt@lkg.dec.com
3am Software Foundry WWW URL: <currently homeless>
Westford, MA Disclaimer: Digital disavows all knowledge
of this message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199509251014.KAA06744>