[RFA] checkpoint / restart, and multi-fork debugging

Michael Snyder msnyder@redhat.com
Sat Dec 10 08:59:00 GMT 2005


Eli Zaretskii wrote:
>>Date: Tue, 06 Dec 2005 14:46:09 -0800
>>From: Michael Snyder <msnyder@redhat.com>
>>
>>OK, ready for submission.
> 
> 
> Thanks!
> 
> My comments, mostly about the manual, are below.

All good suggestions -- I'll incorporate them.


>>+ Set number of finish commands gdb should do on restart of a fork."), _("\
> 
> 
> Can we add some clarification to this text?  I'm not sure users will
> understand what is ``restart of a fork'' and why they'd wish to do
> finish commands then.

Yah, that's a kind of an afterthought.  I noticed that the
"natural" forks (ie. when the user program calls fork directly)
would be preserved somewhere in system / library code before
the return of fork, and that whenever you first start to debug
one, you always have to begin by giving an identical sequence
of "finish" commands, to get back to user code.  Just thought
it might be convenient to automate that.  But I doubt if the
number of stack frames can be hard-coded.

When gdb calls fork to create a checkpoint, this gets taken
care of (mostly) by the mechanics of call_function_by_hand
(or whatever it's called now).

> We should also tell users that `fork' must be compiled and linked into
> the program, or else checkpointing will not work, right?

Yes, that's analogous to the fact that you must have malloc
in the user program in order to allocate string variables.
If I can find how that's documented, I'll immitate it.

> Also, I think these features should be mentioned in NEWS.

Yes.

> Finally, it would be nice to have a short description of the Linux
> implementation of these two features in gdbint.texinfo.

Where might that go, and what might it look like?




More information about the Gdb-patches mailing list