From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24835 invoked by alias); 10 Dec 2005 01:29:45 -0000 Received: (qmail 24823 invoked by uid 22791); 10 Dec 2005 01:29:44 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 10 Dec 2005 01:29:43 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id jBA1TfEX027136 for ; Fri, 9 Dec 2005 20:29:41 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id jBA1TaV11569; Fri, 9 Dec 2005 20:29:36 -0500 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id jBA1TYfU029683; Fri, 9 Dec 2005 20:29:34 -0500 Message-ID: <439A2F7D.5030503@redhat.com> Date: Sat, 10 Dec 2005 08:59:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird (X11/20050322) MIME-Version: 1.0 To: Eli Zaretskii CC: gdb-patches@sources.redhat.com Subject: Re: [RFA] checkpoint / restart, and multi-fork debugging References: <439614B1.2030206@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00189.txt.bz2 Eli Zaretskii wrote: >>Date: Tue, 06 Dec 2005 14:46:09 -0800 >>From: Michael Snyder >> >>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?