From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16437 invoked by alias); 23 Dec 2005 19:53:52 -0000 Received: (qmail 16422 invoked by uid 22791); 23 Dec 2005 19:53:51 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Fri, 23 Dec 2005 19:53:49 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Epsz3-0008Fy-Rv; Fri, 23 Dec 2005 14:53:45 -0500 Date: Sat, 24 Dec 2005 15:30:00 -0000 From: Daniel Jacobowitz To: Michael Snyder Cc: Michael Snyder , gdb-patches@sources.redhat.com Subject: Re: [RFA] Linux Checkpoint/Restart, take 2 Message-ID: <20051223195345.GA31656@nevyn.them.org> Mail-Followup-To: Michael Snyder , Michael Snyder , gdb-patches@sources.redhat.com References: <43A777EE.50404@cisco.com> <20051223142940.GA24997@nevyn.them.org> <43AC53C3.3020902@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <43AC53C3.3020902@redhat.com> User-Agent: Mutt/1.5.8i 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/msg00280.txt.bz2 On Fri, Dec 23, 2005 at 11:45:07AM -0800, Michael Snyder wrote: > >The implementation is almost entirely contained in linux-nat.c and > >linux-fork.c. Maybe we should discuss the target vector interface to > >this before it goes in? For instance, there's no reason a Linux-hosted > >gdbserver shouldn't be able to implement exactly the same thing. > > No, and I fervently hope that other targets will implement something > like it too (I may work on some of them). However, the current patch > is for native linux only, and does not *prevent* any other targets > from implementing checkpoints. That's why I defined all the commands > in a linux-only module. > > I'd like to check in what I have now, and do the target-vectorization > as needed. Having this implementation to play with will help us define > what target vectors we need. Well, OK. > >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? > > No, it actually was needed, and it's a little obscure, so I'll > give you an explanation as a footnote, down below. ;-) Now I'm dying of curiousity. No footnote? > >Why have we got both "info checkpoints" and "info forks"? Right now > >they're aliases to each other and some of the fork commands redirect > >you to info checkpoints. > > Well, because sometimes you'll be using checkpoints, and sometimes > you'll be debugging forks. The underlying functionality is identical, > but users aren't gonna know or care about that -- from their point > of view, they are two entirely different tasks. Hmm. That does make some sense. > >How do you feel about calling this "switch-fork"? If I see a debugger > >command named "fork", my first reaction is going to be that it's an > >active command (creates a fork) instead of a passive one (focuses our > >attention on a different one). > > I see what you mean -- I was just basing it off of the "thread" > command by analogy. I'm not attached to it, though, and would be > happy to hear what others think. Me too. > >Getting at the PC this way is probably going to bite you; the two that > >jump out at me are you've bypassed ADDR_BITS_REMOVE, and you're forcing > >unsigned (which is wrong for MIPS and might result in some strange > >looking PCs). No, I don't have a better idea. > > OK, well... since I have a full-fledged copy of the regcache, > there *must* be a legitimate way to do it. If not, there should > be, and maybe I'll have to add it. ;-) I think you've hit it on the head - there should be, and you may have to add it. This normally passes through gdbarch_read_pc, whose interface is perhaps due for an overhaul to the modern age of regcaches (and/or frames?). -- Daniel Jacobowitz CodeSourcery, LLC