Re: [discuss] Process record -- save and restore to a file

[Greg Law <glaw@undo-software.com>]

Michael Snyder wrote:
> 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.

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/