> is it possible to generate a (fake) core dump of process (with sending
> a signal to process, which is not handled), then transport it together
> with process image (and possibly libraries), and resume execution?
> (the resume part seems to be done in GDB).
I don't know. This would be a bitch of a problem though. You'd have to go
through memory looking for pointers and "fix" them by translating to a new
base address. Often code doesn't contain enough information to do this.
Unless it's compiled with debugging symbols, there's no way to know that the
32-bit value at bp+12 is actually a pointer... I'd suggest doing everything
possible to reproduce the exact memory layout of the "saved" process.
In general this "process moving" isn't feasable, unfortunately. The
solution I came up with was to "stream" the process back to disk. In other
words, have a code module (part of the program) that writes all its data
structures to disk in a reasonable fashion. This is easiest in an OOP
environment, where objects can have a method to "stream" or "flatten"
themselves. Pointers can be turned into references that make sense on disk,
open files can be flushed and closed in an orderly fashion, etc.
Couple of things to think about:
1) you have to re-fix up the load address, library addresses, stack frame,
code and data segments, and any mmap()'ed data.
2) You have to "fix" every single pointer in the memory space, unless you
manage to get all the pointers in (1) the exact same as before.
3) you have to re-open any files in use, and make sure the fd's are the
same.
4) you have to recreate open network sockets.
-- Bob
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-- Benjamin Franklin
Bob McElrath (rsmcelrath@students.wisc.edu) Univ. of Wisconsin at Madison
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/