Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!umd5!mimsy!chris From: chris@mimsy.UUCP (Chris Torek) Newsgroups: comp.unix.questions Subject: Re: Core files ... still trying Keywords: core Message-ID: <12232@mimsy.UUCP> Date: 29 Jun 88 18:47:55 GMT References: <344@ajpo.sei.cmu.edu> <441@anagld.UUCP> <790@scubed.UUCP> <537@philmds.UUCP> Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 49 >In article <796@scubed.UUCP> warner@scubed.UUCP (Ken Warner) writes: >>[an example unexec()] >>It does work (sort of), but when the new executable is run, a segmentation >>violation occurs in the clean up on exit. ... In article <537@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >You do not copy the BSS space nor any extension of the data space ... Leo is correct here; but: >But of course you cannot include a BSS in your executable; while you can provide BSS in the new a.out, that is the wrong tack. Instead, what was originally BSS, and any new data allocated via sbrk(), must be saved in a new (larger) data segment in the new a.out. This tends to make enormous a.out files; it sometimes helps not to write blocks of zeroes, instead allowing them to be holes. (Paging from a hole should work, and does under 4BSD.) >And I also would like to know what use this scheme has? That depends. A general restart mechanism can be handy. Unexec is not so general, but sometimes works. >Is it for speedup of programs that do a lot of processing, table >creation and the like before actually taking off? Then I've got an >alternative: write out the complete data space, and when you start >up again, sbrk to the correct position ... and read it in. Sendmail does this, and I hate it. Every time you recompile the binary you have to do this again. It also has some problems: >... The only problem I had with some variables that point into a >different space, for instance environ in the BSS that points to >the stack. Just saving before and restoring after the read of the >datafile solved this. I prefer systems that save the data they want saved, rather than blindly saving everything. It is easy to imagine a library routine (malloc or curses) that does something once on startup to get some important information which may change from run to run (available memory space or $TERM). If the call has occurred once already, the wrong data will be used next time. Ever wonder why rogue used to refuse to work right on a different kind of terminal when restoring a saved game? . . . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris