Core files ... still trying

[Chris Torek]

>In article <796 at scubed.UUCP> warner at 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 at philmds.UUCP> leo at 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 at mimsy.umd.edu	Path:	uunet!mimsy!chris