NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/unix/programm/3971

Internet Message Format | 1992-07-28 | 3.5 KB

Xref: sparky comp.unix.programmer:3971 comp.unix.questions:9507 gnu.misc.discuss:2569 gnu.gcc.help:1802 comp.unix.ultrix:5946
Path: sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!drutx!drbug3!ldg
From: [e-mail] (Doug Gibbons)
Newsgroups: comp.unix.programmer,comp.unix.questions,gnu.misc.discuss,gnu.gcc.help,comp.unix.ultrix
Subject: Re: help with unexec
Message-ID: <[e-mail]>
Date: 28 Jul 92 15:16:05 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Organization: AT&T Bell Laboratories
Lines: 62


  41593    Re: help with unexec                          [35] Oliver Laumann      In article <[e-mail]>, [e-mail] (Oliver Laumann) writes:
|> [e-mail] (David Nicodemus) writes:
|> > I am looking for a way to force a program out of execution, and save an
|> > image of the program that can be restarted from the same point at a later
|> > time.
|> >
|> > It appears that the gnu unexec() function from gnu emacs will do this;
|> > however, the last parameter asks for a "starting address."
|> >
|> > How can I find this "starting address" (which I want to be the current
|> > point of execution)?  Is this even possible?
|>
|> I'm not sure I understand what exactly you want to accomplish.  You
|> certainly cannot *force* a program to dump its image to disk using
|> unexec(); the program must call unexec() voluntarily.

But you can. Look at gcore(1) on SunOS and SVR4. This is a ptrace(2) and
/proc -based utility which can generate a snapshot core image of a running
process. But, note that core files usually do not have a copy of the executable
text - this would have to be recovered from the original a.out, and any shared
object libraries that were loaded.

Many pieces of the process context are difficult, if not impossible to
either capture and/or reconstruct:

    - open file context, including tty
    - STREAMS context
    - mapped-file context (/proc gives you inode #, but not file name)
    - SIGNALS context (try reconstructing a process that was unexeced while it
      was in a signal handler)
    - IPC context
|>
|> The entry point you can supply to unexec() is the address where the
|> a.out file produced by unexec() will start when it is invoked later.
|> Every a.out file has an entry point; it's part of the a.out header.
|>
|> Anyway, when using unexec(), you cannot have the newly created a.out
|> file resume execution at the point where the original invocation saved
|> its image.  To be able to do this, unexec() would have to save not only
|> the text and data segment of the running program, but also the entire
|> execution state (stack and registers).
|>

True, unexec would have to restore the execution state. Data, stack and registers
can be recovered from the core file. Text must be recovered from the original
a.out and any associated shared libraries. The entry point for the new
executable image could be a strip of code which performs

    - reloading of the registers, old pc last. Restoring privileged bits
      in whatever your psw is could be tricky or downright impossible.
    - re-establishment of the prior stack context - restoring the sp is
      not nearly enough!
    - resetting the brk value. The initial break value can be determined by
      summing the .data and .bss-like sections of the a.out


--
--------------------------------------------------------------------------------
-- Doug Gibbons            | [e-mail] or att!druhi!ldg
-- AT&T Bell Laboratories
-- Denver CO