From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32694 invoked by alias); 23 Dec 2005 21:52:09 -0000 Received: (qmail 32687 invoked by uid 22791); 23 Dec 2005 21:52:09 -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; Fri, 23 Dec 2005 21:52:08 +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 jBNLq6MG016788 for ; Fri, 23 Dec 2005 16:52:06 -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 jBNLq5106111; Fri, 23 Dec 2005 16:52:06 -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 jBNLq4Va022996; Fri, 23 Dec 2005 16:52:04 -0500 Message-ID: <43AC7183.2080406@redhat.com> Date: Sat, 24 Dec 2005 16:15:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird (X11/20050322) MIME-Version: 1.0 To: Daniel Jacobowitz CC: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFA] Linux Checkpoint/Restart, take 2 (footnote) References: <43A777EE.50404@cisco.com> <20051223142940.GA24997@nevyn.them.org> In-Reply-To: <20051223142940.GA24997@nevyn.them.org> 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/msg00282.txt.bz2 Daniel Jacobowitz wrote: > I totally don't understand what the clobber_regs bits are for. You're > using fork as a backend; each saved fork had better have both its own > registers, right? Is it just a GDB internal bookkeeping thing? If so, > why do you need to do it for saved forks and not for the existing > follow-fork bits? OK, here's the thing. If we switch contexts to a fork that was actually created by the user process, we actually don't need the saved copy of the regcache -- we can simply allow gdb to fetch the regs from the "new" inferior_ptid. But if we do that for a checkpoint fork, it's not gonna work, because when THAT process was created, it was in a function (fork) that was called by gdb. So its register state and stack are in the state as set up by Call-Function-By-Hand. In other words, when it was "frozen", it was before returning to CFBH, and therefore CFBH had not yet had a chance to restore the pre-CFBH register state. So we have to do that now. It's just a bit of post-cleanup from after the CFBH state, and we don't in fact want to do it for the "natural" forks, because if we did, we would be restoring the register state of the parent, not the child, and that would (usually) include the return value of fork. Not good. In the case of the gdb-created forks, we actually *want* to restore the parent's register state. Hence the difference. Clear now? ;-) Michael