Re: load and use a ".o" file?

[Mark H Johnson <Mark_H_Johnson@raytheon.com>]

lifetime n00b wrote:
> Stephen Leake wrote:
> 
>> .dll and .so files are designed to do _precisely_ what you are trying
>> to do; they are the most efficient solution!
> 
> 
> Well, not _precisely_, since a typical program using the .dll or .so 
> files needs to know about those files when it is compiled itself, right? 
> Maybe I wasn't clear on exactly what I need to do. The program that 
> needs to load and use the object file is *already running* before the 
> object file is compiled. This "main program" has no prior information 
> about the data or routines which may be in the object file it is being 
> told to load.
> 
What you are describing sounds a lot like the mechanism used on Multics 
for dynamic linking of object files. There is a better explanation in 
the references at
   http://www.multicians.org/
or by reading
   "The Multics System: An Examination of its Structure" by E.I. Organick
but a quick summary follows.

When a file is compiled on Multics, an object file is created. Part of 
the data in that object file is a list of public symbols, including 
entry points. For a subroutine named xyz, compiled from xyz.fortran, the 
  entry point would simply be xyz. Let's say you have a main program 
main, calling xyz. This is an external reference to xyz (since it is not 
found in the current segment), and the first call works something like this:
  - call xyz (dispatched to an activation function)
  - the activation function checks first the active segments for a 
symbol within them called xyz. If found, it fixes up the dispatch to go 
directly to that xyz and resumes execution.
  - if not in an active segment, it uses the search path (similar to 
PATH on Unix) to find a file named xyz. If found, it loads that file 
into a segment, makes it active, and does the work of the second step.
  - if no such file is found, it calls the command line interpreter with 
an error status. At this point, you can fix your search path, create the 
object file xyz, start the debugger, or abandon execution. If you either 
of the first two, you can resume and the attempt to load xyz repeats.

The subsequent calls to xyz is done just like any other cross segment 
function call, basically running at (or near) full speed. It is this 
part that eliminates most of the concerns about performance since the 
expensive look up is only done once per symbol.

This capability, and I/O redirection are two of the things I really miss 
from Multics. The development flexibility provided were great to enhance 
the performance of developers and the overhead was quite modest with the 
hardware provided. The lack of effective paged / segmentation hardware 
is one thing that makes this hard to implement in software.

You can probably get close if you modify the build of objects to 
generate .so's instead of .o's and then put a wrapper around dlopen to 
do the semantics you are looking for. If you use GNAT, you could 
probably even bury this in the runtime by adding a pragma (or command 
line option) to denote external references as dynamic calls.

If you get this to work, I'd like to hear about it.
   --Mark