Process Execution with Non-Standard Entry Points

[P. D. Guthrie]

In article <354 at mcgill-vision.UUCP> mouse at mcgill-vision.UUCP writes:
>
>     Ptrace might be used to  do this,  but  it can get awkward.   I put
>this  in our kernel; it isn't very difficult (4.2bsd) if you have kernel
>source.  Unfortunately, you cannot have ANY  files open at the time  you
>make the dump (open files looked like too much of a headache to save the
>state of,  so  I let the programmer  worry about closing  and re-opening
>files).  It works OK; people  here use it  as a checkpoint mechanism for
>programs  which take  cpu-hours or  cpu-days.   If  anyone out  there is
>interested, mail me (see  the  .signature  below)  and I  can  give  you
>details, or if you have a  source license we can work  out something for
>getting you the code.
>-- 

Or of course if you know in advance what processes you want to do this
to, simply write into the code a routine to dump all the info you want,
assign it to a signal and just `kill' it from the shell.  Much much
easier.  I used this on a process that soaked up excess CPU time (was
running niced at +19) by calculating e, and when ever I wanted to get
the current approximation, I sent SIGINT to it, and it made a file
/usr/tmp/e with the current answer.
This tecnique does not have anywhere near the flexability of some type
of ptrace routine,  but it is simple enough that I thought it worth
mentioning.
-- 

Paul Guthrie				`When the going gets weird,
ihnp4!ihdev!pdg				 The weird turn pro'
					  - H. Thompson