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