Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!ucbvax!ICAEN.UIOWA.EDU!dbfunk
From: dbfunk@ICAEN.UIOWA.EDU (David B. Funk)
Newsgroups: comp.sys.apollo
Subject: Re: undump/preloaded tex on apollo domain systems
Message-ID: <8809220331.AA11747@umaxc.weeg.uiowa.edu>
Date: 22 Sep 88 02:59:14 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: Iowa Computer Aided Engineering Network, University of Iowa
Lines: 47

In several articles there have been discussions about dumping
"frozen" versions of Unix programs:

<16054@shemp.cs.ucla.edu>, scott turner (srt@cs.ucla.edu)
GBOPOLY1@NUSVM.BITNET (fclim)
<16115@shemp.CS.UCLA.EDU>, scott turner (srt@cs.ucla.edu)

In the last of these, Scott writes:

>GNU EMACS is dumped during the building process by creating a freeze file
>containing all of EMACS's impure state; the freeze file is called "emacs.dump"
...
>Note that in order for dumped EMACS's to function properly, you must have the
>DOMAIN csh variable "inprocess" unset, so that executing EMACS causes a fresh
>process to be created, and hence causes EMACS to be loaded at the same point in
>memory as when it was dumped.  For this reason, you must also have "inprocess"
>unset when you make EMACS.
...

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 very 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 very 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.
    I prefer the ease of program development and the space savings allowed by
global libraries to the dubious benefits of "frozen" binaries. I hope that
Apollo never abandons them.

Dave Funk
Iowa Computer Aided Engineering Network (ICAEN)
University of Iowa, Iowa City, IA
dbfunk@icaen.uiowa.edu