|Dynamic compilation/linking email@example.com (Steve Boswell) (1991-12-05)|
|Re: Dynamic compilation/linking oliver@madrone.CS.Berkeley.EDU (1991-12-07)|
|Re: Dynamic compilation/linking firstname.lastname@example.org (1991-12-10)|
|Re: Dynamic compilation/linking email@example.com (Marc Sabatella) (1991-12-11)|
|Re: Dynamic compilation/linking firstname.lastname@example.org (1991-12-12)|
|Re: Dynamic compilation/linking email@example.com (1991-12-13)|
|Re: Dynamic compilation/linking firstname.lastname@example.org (1991-12-17)|
|From:||email@example.com (Parag Patel)|
|Organization:||Netcom - Online Communication Services (408 241-9760 guest)|
|Date:||Tue, 17 Dec 91 01:56:38 GMT|
This may be drifting off of the original topic, but there are other
methods and uses of dynamic linking. I wrote a dynamic-linking library
quite a while ago which performs dynamic linking of *.o object files,
dynamic unlinking, relinking, and autolinking upon execution.
The library is designed to be imbedded in user code. It does not use the
ld command at all but rather performs the linking and relocation itself.
The most interesting part is the autoloading. Most linkers and dlinkers
insist upon resolving all unknown references before execution. My dld
package will instead patch all the unknowns in an object file to point to
"stub" routines when that object is loaded.
When (if) these functions are called, then the stub will search for the
real object file to load in, load it, then jump to the real routine, after
marking themselves for later deletion. When an object file is unloaded,
all its function entry points are replaced by stubs.
All this makes for a truly dynamic programming environment that behaves
much like an interpreted one. It has been quite useful in tools such as a
prototype Motif builder where it takes forever to do a link when only one
or two files are changed.
There are additional features to allow unloading data as well as code, to
support changing C++ virtual-table sizes, for instance. dld searches for
objects both along a search path and within a set of *.a libraries. It is
possible to setup autoloads for every function within a library, just on
the off chance that you may feel like calling something there. There's
even a Tcl interface for dld.
Only a source-level debugger is not supported. I have had plans for a
dynamically loaded debugger module for on-the-fly debugging, but never had
the time or need to write one. It is possible to run the host debugger on
a program doing dynamic-linking, but it isn't possible to view or
manipulate the dlinked code.
The library only works on (M68K based) A/UX and HP s300s right now. It
has a machine-independent interface and some heavily machine-dependent
code. I could port it to other hardware, but have never had the need (nor
the hardware). The code has been distributed on the HP Interex
contrib-tape, so I can make my current code available to anyone who wants
it. Just drop me email at <firstname.lastname@example.org>.
Return to the
Search the comp.compilers archives again.