This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Tom Tromey wrote:
"Michael" == Michael Snyder <msnyder@redhat.com> writes:


Michael> OK, ready for submission.
Michael> This patch adds two new functionalities for linux native debugging:
Michael>    * Multiple fork debugging, and
Michael>    * Checkpoint / Restart.

I know nothing about the patch of course, but this looks like an
excellent feature.  One thing that amazes me about it is that it is
conceptually simple but I don't recall ever hearing it as an idea
until recently.

It's an idea that Stan Shebs and I have been kicking around for years. By the way, Stan is the one who thought of using fork to capture the state -- I've been very remiss about giving him credit for that.

One thing I didn't see mentioned in the docs is the effect on gdb of a
'restart'.  I assume that new breakpoints, watchpoints, etc, are kept
instead of reverting to the state at the checkpoint.  Maybe this is
worth mentioning.

Yes, thanks -- I'll work it in. You're correct, checkpoint only preserves the inferior's state, not the debugger's. All breakpoints and watchpoints are shared between checkpoints and/or forks.

A nice problem this solves is handling watchpoints when the system has
address space randomization.  I run into this all the time when
debugging -- back before this feature was added to the OS I would put
a fair amount of effort into finding some address to watch in one
debug session, then restart the inferior with a watchpoint set.
Randomization made this impossible; but with this patch I could just
make a checkpoint at 'main'.

True that.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]