RE: [RFC] New gdb command 'gcore'

[Andrew Volkov <Andrew.Volkov@transas.com>]

> 
> > The holy grail, of course, would be to then give gdb the ability to
> > restart the process from the core file state.  That would give us a
> > checkpoint-and-restart capability that very few debuggers have ever
> > had.  But that's down the line...
> 
> Unfortunately in general a normal core file does not contain enough
> information to allow a process to be restarted, since it doesn't
> contain a lot of the information in the kernel which forms part of the
> process' state.
> 
> There are many "fun" issues which arise when trying to implement
> checkpointing, such as
> 
> 1) Open files. What fds ar open ? What's the seek position of each ?
>    What about pipes ?
> 
> 2) process id; does it change between the original process and its
>    reincarnation ?)
> 
> 3) parent process id (same question).
> 
> 4) relationship with child processes (if any). Do you checkpoint the
>    whole process group ?
> 
> 5) network connections. Can you reconstruct them ? What about the
>    state of the other end ?
> 
> 6) time. When the process is reincarnated does it see time passing
>    while it was only a checkpoint ?
> 
> 7) signal handling state. What signal handlers are set up ? What
>    signals are blocked ? 
> 
> 8) State of any timers. Suppose a thread was in a sleep() when should
>    the sleep complete ?
> 
> 9) State of other potentially long system calls. A listen(), for
>    instance, or a read from something which isn't ready.
> 
> 10) All the other things which didn't come to mind in the 
> three minutes
>    it's taken to type this.
> 
> Of course it's possible to add restrictions to the state a process
> must be in before it can be checkpointed, unfortunately if you want to
> do the checkpoint from gdb it's going to be hard to know if the
> restrictions are valid, since you can arbitrarily invoke gcore between
> any two machine instructions.
> 
> It's a nice idea, but I think it's hard :-( (and to do it portably is
> _very_ hard).

All this problems correct for remoute/native debugging, but how about 
implementing this in sim? I think this will useful for embeded programming.

Andrey Volkov