From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3638 invoked by alias); 13 Oct 2009 19:08:31 -0000 Received: (qmail 3624 invoked by uid 22791); 13 Oct 2009 19:08:30 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00 X-Spam-Check-By: sourceware.org Received: from smarthost01.mail.zen.net.uk (HELO smarthost01.mail.zen.net.uk) (212.23.3.140) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Oct 2009 19:08:26 +0000 Received: from [82.71.15.62] (helo=[192.168.123.72]) by smarthost01.mail.zen.net.uk with esmtpsa (SSL 3.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1MxmjQ-0001y6-4k; Tue, 13 Oct 2009 19:08:24 +0000 Message-ID: <4AD4D027.8080806@undo-software.com> Date: Tue, 13 Oct 2009 19:08:00 -0000 From: Greg Law User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Michael Snyder CC: "gdb@sourceware.org" Subject: Re: [discuss] Process record -- save and restore to a file References: <4AD35518.9040606@vmware.com> <4AD4CABC.3060202@undo-software.com> <4AD4CCB4.9000900@vmware.com> In-Reply-To: <4AD4CCB4.9000900@vmware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Originating-Smarthost01-IP: [82.71.15.62] Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00246.txt.bz2 Michael Snyder wrote: > Greg Law wrote: >> Michael Snyder wrote: >>> [..] >>> >>> Secondly, I have a suggestion about the command names. >>> How about >>> record save >>> record restore >>> instead of >>> record dump >>> record load >>> >>> What do you guys think? >> >> UI looks good to me, too. >> >> Would we expect these commands to be reflected over the remote >> protocol if a remote target were using reverse debugging? > > No, just as with core files, we've never made the final effort > to get gdb to suck all the information out of the remote target. > > And since this feature involves saving a core file, you can > imagine how much data we would be transporting. > > If we did corefiles first, I don't imagine it would be too hard > to get the rest of this to work. Oh, I wasn't imagining sucking the entire record log from the remote target into gdb. I was thinking of driving the saving/restoring of remote logs from gdb itself. So say you have gdb attached to a reversible debugging session on VMware or UndoDB or Simics or whatever, you could issue 'record save' and have the backend dump its log to disk in some format the backend understands. Likewise 'record restore' would cause send a packet to the backend causing the backend to suck in the logfile. The various backends could probably have their own interfaces to do this stuff, but it would seem nicer to have a "proper" interface for this at the gdb level. Greg -- Greg Law, Undo Software http://undo-software.com/