Path: utzoo!attcan!uunet!ncrlnk!ncrcae!ece-csc!ncsuvx!gatech!cwjcc!tut.cis.ohio-state.edu!mailrus!utah-gr!utah-cs!hollaar
From: hollaar@utah-cs.UUCP (Lee Hollaar)
Newsgroups: comp.sys.apollo
Subject: Re: undump/preloaded tex on apollo domain systems
Summary: It's possible to dump apollo programs and run them on other nodes!
Message-ID: <5743@utah-cs.UUCP>
Date: 22 Sep 88 16:08:36 GMT
References: <8809220331.AA11747@umaxc.weeg.uiowa.edu>
Reply-To: hollaar@cs.utah.edu.UUCP (Lee Hollaar)
Organization: University of Utah CS Dept
Lines: 68

In article <8809220331.AA11747@umaxc.weeg.uiowa.edu> dbfunk@ICAEN.UIOWA.EDU
(David B. Funk) writes:

>One aspect of this issue that should be mentioned is that the whole concept
>of "frozen" executables runs counter to the current Apollo Domain environment
>The Domain environment (pre SR10) is based upon position-independent code,
>installed global libraries, and dynamic binding and relocating at load time.
>Thus the load point and global references can vary from one program run to
>the next. At SR9.5 the base load point was moved to low memory and a fixed
>point, in preparation to supporting COFF and absolute code. Thus when loading
>a program into a fresh process (not inprocess) the load point would be fixed.
>This would seem to make a "frozen" load possible. But the actual addresses of
>globals will vary from one type of node to another, and even can vary on
>similar node types, depending upon the set of installed global libraries. For
>example try a "/com/esa fprintf" on both a DN3000 and DN4000 and look at the
>results. So you would end up having to bind statically in all the libraries
>needed to insure fixed resolutions for all global symbols, start it in a fresh
>process & dump it. Then you could only run it in a fresh process each time.
>This would result in wasting large amounts of disk and memory space. Is it
>worth it?
>   At SR10 the compilers produce absolute code by default and the environments
>are configured to better support fixed references. But even then, a "frozen"
>program could still run into trouble due to differences in installed global
>libraries.

Surprisingly, the change at SR9.5 to have programs start loading at a fixed
location in memory was the only change necessary to the Domain environment
in order to support dumping of an executing program with its current state
and restarting it at some later time on another node, even if that node was
a different type.  (Unfortunately, some shells didn't get moved into high
memory when the memory allocation scheme was changed, but Apollo seems to
have gotten most of them by now.)

Before I get flamed too much about not understanding global libraries and
that they are in different places on different node types, let me explain
that about a year ago I wrote a program as part of the port of Spitbol (a
fast version of SNOBOL4) that dumps an image of an executing Spitbol program
at the point where the dump function is called.  When that image is run as
a normal program, execution begins at the start of the original program,
which contains code that determines if this is a restart and if so, reloads
a saved stack and returns to the point where the dump was called.  Even a
restarted dumped program can call the dump routine again, establishing a
program further along in its execution.  The dumped programs have been
produced on one node type and run on another (primarily DN300, DN330,
DN3000, and DN4000) with no problem with the fact that the global libraries
are in different places.

The trick is that the dumped program must not contain an absolute address
to the global library entry points.  All other addresses are fine, since
the new loader conventions will assure that the program and its data area
will be loaded at the same place.  My dump program gets a copy of the
original program from the disk (in .obj form), and walks it simultaneously
with memory, determining if a location contains an address to the global
libraries.  (They are marked in the original program so that the loader
can resolve them, and new ones can't be created.)  Any global reference
is changed into the appropriate values for the loader.  When the dumped
program is reloaded, the standard Apollo loader plugs the correct values
for the current global library into the locations, same as for any normal
program.

The only restriction is that the address of a global library entry can't
be assigned to another location, since the unloader won't find it.  So
you shouldn't do an assignment of a pointer to a global library function.
One can probably live with that.

                          Lee Hollaar
                          Department of Computer Science
                          University of Utah