Re: [RFC] New gdb command 'gcore'

Re: [RFC] New gdb command 'gcore'

[James Cownie]

> 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).

-- Jim 

James Cownie	<jcownie@etnus.com>
Etnus, LLC.     +44 117 9071438
http://www.etnus.com

RE: [RFC] New gdb command 'gcore'

[Andrew Volkov]

> 
> > 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

Re: [RFC] New gdb command 'gcore'

[Frank Ch. Eigler]

Andrew Volkov <Andrew.Volkov@transas.com> writes:

: [...]
: > 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.
: > [...]
: 
: All this problems correct for remoute/native debugging, but how about 
: implementing this in sim? I think this will useful for embeded programming.

Many of these issues don't arise in embedded system simulators that
don't provide a full UNIX-style process model (virtual memory, I/O,
etc.), so state save/restore is not that hard.  Our SID simulator has
some native (gdb-independent) state save/restore functionality, for
example, and it can include simulated I/O hardware.


- FChE

[RFC] New gdb command 'gcore'

[Michael Snyder]

I would like to discuss adding a new command 'gcore' to gdb. 
This is at a very early stage, I just want to sound people out 
about it.

The idea is that 'gcore' would cause gdb to generate a core image
of the inferior program (just like the 'gcore' unix command).
The user could drop a core file at any point in the inferior's
execution, and save the memory and register state for debugging later.
We ought to be able to cook up an elf core file pretty easily using
bfd.

This would probably require one or more new target and/or architecture
vectors, for instance to get a list of memory regions in use (which 
would be easy for a /proc target, but might be progressively harder
for ptrace, sim, remote...).  Some targets may not be able to 
implement it right away, but in principle it could even be made
to work for remote embedded targets.

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...