From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-35972-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 10167 invoked by alias); 13 Oct 2009 18:58:47 -0000
Received: (qmail 10152 invoked by uid 22791); 13 Oct 2009 18:58:47 -0000
X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 	tests=AWL,BAYES_00
X-Spam-Check-By: sourceware.org
Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Oct 2009 18:58:44 +0000
Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) 	by smtp-outbound-2.vmware.com (Postfix) with ESMTP id C4D951221C; 	Tue, 13 Oct 2009 11:58:41 -0700 (PDT)
Received: from [10.20.94.141] (msnyder-server.eng.vmware.com [10.20.94.141]) 	by mailhost2.vmware.com (Postfix) with ESMTP id A26478E86D; 	Tue, 13 Oct 2009 11:58:41 -0700 (PDT)
Message-ID: <4AD4CCB4.9000900@vmware.com>
Date: Tue, 13 Oct 2009 18:58:00 -0000
From: Michael Snyder <msnyder@vmware.com>
User-Agent: Thunderbird 1.5.0.12 (X11/20080411)
MIME-Version: 1.0
To: Greg Law <glaw@undo-software.com>
CC: "gdb@sourceware.org" <gdb@sourceware.org>
Subject: Re: [discuss] Process record -- save and restore to a file
References: <4AD35518.9040606@vmware.com> <4AD4CABC.3060202@undo-software.com>
In-Reply-To: <4AD4CABC.3060202@undo-software.com>
Content-Type: text/plain; charset=iso-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2009-10/txt/msg00245.txt.bz2

Greg Law wrote:
> Michael Snyder wrote:
>> [..]
>>
>> Secondly, I have a suggestion about the command names.
>> How about
>>   record save <filename>
>>   record restore <filename>
>> instead of
>>   record dump <filename>
>>   record load <filename>
>>
>> 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.