From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,fcc2d88d867060e8 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2003-12-22 07:50:27 PST Path: archiver1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!crtntx1-snh1.gtei.net!cambridge1-snf1.gtei.net!news.gtei.net!bos-service1.ext.raytheon.com!dfw-service2.ext.raytheon.com.POSTED!not-for-mail From: Mark H Johnson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: load and use a ".o" file? References: <132Fb.3462$I02.2996@newssvr23.news.prodigy.com> In-Reply-To: <132Fb.3462$I02.2996@newssvr23.news.prodigy.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <6pEFb.418$b77.552@dfw-service2.ext.raytheon.com> Date: Mon, 22 Dec 2003 09:50:12 -0600 NNTP-Posting-Host: 192.27.48.39 X-Complaints-To: news@ext.ray.com X-Trace: dfw-service2.ext.raytheon.com 1072108226 192.27.48.39 (Mon, 22 Dec 2003 09:50:26 CST) NNTP-Posting-Date: Mon, 22 Dec 2003 09:50:26 CST Organization: Raytheon Company Xref: archiver1.google.com comp.lang.ada:3698 Date: 2003-12-22T09:50:12-06:00 List-Id: 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