jth@linus.UUCP (Joseph T. Healey) (01/13/86)
I am interested in taking a "snapshot" of a running process, stopping execution, and the resuming execution at the instruction after the stop. I have success- fully copied the state of the text, data and stack segments and constructed a new a.out header specifying a new entry point (a_entry). The program calls a function apon receiving a SIGINT signal and sets the new (desired) entry point from the saved PC on the stack, however when I try to run the new program it always segmentation faults. I can specify any function address in the program as the entry point and the program can be successfully run. I am assuming the since I am trying to start at the saved PC instruction that it should be on a correct instruction address. Does anyone have any ideas about how I can start the execution of a program at an instuction other than a function address?? Any insight at all would be appreciated. Joseph T. Healey Technical Staff Mitre Corp. 617-271-8369 linus!jth@MITRE-BEDFORD
zben@umd5.UUCP (01/16/86)
In article <122@linus.UUCP> jth@linus.UUCP (Joseph T. Healey) writes: >I am interested in taking a "snapshot" of a running process, stopping execution >and then resuming execution at the instruction after the stop. I have success- >fully copied the state of the text, data and stack segments and constructed a >new a.out header specifying a new entry point (a_entry). > >The program calls a function upon receiving a SIGINT signal and sets the >new (desired) entry point from the saved PC on the stack, however when I try >to run the new program it always segmentation faults. I can specify any >function address in the program as the entry point and the program can be >successfully run. > >I am assuming the since I am trying to start at the saved PC instruction that >it should be on a correct instruction address. Does anyone have any ideas >about how I can start the execution of a program at an instruction other >than a function address?? Any insight at all would be appreciated. If I understand you correctly, you are trying to write out a new "a.out" file that, when executed, will pick up where the program that wrote it out left off?... Well, you will lose position on all your files and stuff. You don't mention the exact machine and Unix you are using. On many systems the initial register contents are undefined, or defined to be something (like "stack pointer starts at top of current stack page") not characteristic of a *running* program. If this turns out to be the problem, save everything explicitly in an area of the image that you define, and make the ACTUAL entry point in YOUR code somewhere, and after it has reloaded everything, LEAP to where you would reenter the code. A good place for this would be the subroutine that actually writes the a.out file. Of course, I could be *totally* off base... -- "We're taught to cherish what we have | Ben Cranston by what we have no longer..." | zben@umd2.umd.edu ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
zben@umd5.UUCP (01/17/86)
In article <833@umd5.UUCP> zben@umd5.UUCP (Ben Cranston) writes: >In article <122@linus.UUCP> jth@linus.UUCP (Joseph T. Healey) writes: >>I am interested in taking a "snapshot" of a running process, stopping ... >> ... Does anyone have any ideas >>about how I can start the execution of a program at an instruction other >>than a function address?? Any insight at all would be appreciated. > >If this turns out to be the problem, save everything explicitly in an area >of the image that you define, and make the ACTUAL entry point in YOUR code >somewhere, and after it has reloaded everything, LEAP to where you would >reenter the code. ... I haven't been working with Unix all that long. My comment about losing the file position was WAY off base, although one would have to ensure that the connected files get reconnected and pipes would have problems. But, it occurs to me that the "setjump/longjump" suite, if available on your machine, does pretty much what you want to do. When you get down into the signal catcher, do a "setjump" before writing the a.out file. Arrange to do a "longjump" back when the program is restarted. Also note that many Unix systems have a "preload" that is inserted by the loader, which usually does some things to set up argc and argv, then calls or leaps to entry point "main". If you have one of these, you may NOT want to change the entry point in the a.out header. Instead, you may want to change the leap or call instruction at the end of the preload to go off to your function that eventually "longjump"s back to the signal handler. Without knowing the hardware or dialect of Unix it is hard to say more. -- "We're taught to cherish what we have | Ben Cranston by what we have no longer..." | zben@umd2.umd.edu ...{seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben
yamo@ames-nas.arpa (Michael J. Yamasaki) (01/23/86)
>In article <122@linus.UUCP> jth@linus.UUCP (Joseph T. Healey) writes: >>I am interested in taking a "snapshot" of a running process, stopping execution >>and then resuming execution at the instruction after the stop. I have success- >>fully copied the state of the text, data and stack segments and constructed a >>new a.out header specifying a new entry point (a_entry). >> >>The program calls a function upon receiving a SIGINT signal and sets the >>new (desired) entry point from the saved PC on the stack, however when I try >>to run the new program it always segmentation faults. I can specify any >>function address in the program as the entry point and the program can be >>successfully run. >> >>I am assuming the since I am trying to start at the saved PC instruction that >>it should be on a correct instruction address. Does anyone have any ideas >>about how I can start the execution of a program at an instruction other >>than a function address?? Any insight at all would be appreciated. I missed the original article, but ... It seems that what you might be interested in is ptrace(2). It is used for the implementation of breakpoint debugging (check out adb, sdb, dbx sources). Enjoy. -Yamo-
mouse@mcgill-vision.UUCP (01/27/86)
key: > yamo@ames-nas.arpa (Michael J. Yamasaki) >>> yamo attributes to jth@linus.UUCP (Joseph T. Healey) >>> I am interested in taking a "snapshot" of a running process, >>> stopping execution and then resuming execution at the instruction >>> after the stop. I have successfully [ attempted to build a new >>> a.out ] >>> [ but the new a.out segmentation faults ] > > I missed the original article, but ... I'm afraid I did too. Miss the original, that is. But the request seems clear enough. > It seems that what you might be interested in is ptrace(2). 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. -- der Mouse USA: {ihnp4,decvax,akgua,etc}!utcsri!mcgill-vision!mouse philabs!micomvax!musocs!mcgill-vision!mouse Europe: mcvax!decvax!utcsri!mcgill-vision!mouse mcvax!seismo!cmcl2!philabs!micomvax!musocs!mcgill-vision!mouse Hacker: One who accidentally destroys / Wizard: One who recovers it afterward
pdg@ihdev.UUCP (P. D. Guthrie) (01/30/86)
In article <354@mcgill-vision.UUCP> mouse@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