GBOPOLY1@NUSVM.BITNET (fclim) (09/21/88)
i believe there's no way to bring up a preloaded tex on an apollo at sr9.7 because there is no way to dump an image of the running tex. maybe, this is *fixed* at sr10. in article <16054@shemp.cs.ucla.edu>, scott turner (srt@cs.ucla.edu) writes: >described in an earlier message. If you are *real* interested in >building a pre-dumped version, you might want to look at how GNU >Emacs works on the Apollos. i doubt if adding some code from gnu emacs to tex will help. otherwise, we should also be able to have a preloaded emacs. basically, what you (and i and many other people) should do is to shout to apollo.com for them to put back some vanilla into their domain/ix. i would like "kill -quit" to dump a core which may be undump-ed. the core may be used with /com/debug so that i may debug my program in the middle and not always with main(). fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513.
srt@maui.cs.ucla.edu (Scott Turner) (09/22/88)
GBOPOLY1@NUSVM.BITNET (fclim) writes: > >in article <16054@shemp.cs.ucla.edu>, scott turner (srt@cs.ucla.edu) >writes: > >>described in an earlier message. If you are *real* interested in >>building a pre-dumped version, you might want to look at how GNU >>Emacs works on the Apollos. > >i doubt if adding some code from gnu emacs to tex will help. otherwise, >we should also be able to have a preloaded emacs. From the APOLLO file that comes with Zubkoff's Emacs fixes: ... 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" and is stored in the "etc" directory named by PATH_EXEC in "paths.h". If you must rebuild EMACS for any reason, after performing the make in the "src" directory you must move the file "temacs" to "../emacs" and the file "temacs.dump" to "../etc/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. ... So Emacs does do something like a dump/undump, leaving you with an executable preloaded Emacs. Whether these changes would be difficult to apply to TeX I can't say. -- Scott Turner Scott R. Turner UCLA Computer Science "Understanding 'em is Knowing how to Break 'em" Domain: srt@cs.ucla.edu
dbfunk@ICAEN.UIOWA.EDU (David B. Funk) (09/22/88)
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
hollaar@utah-cs.UUCP (Lee Hollaar) (09/22/88)
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