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

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

[Michael Snyder]

OK, we set this discussion aside over a month ago, until after 7.0.
Time to revive it?  Seemed like the implementation discussion had
more or less stabilized, and we were mostly still discussing the
user interface and docs -- so let's start there.


In the last cycle, we had come down to a UI that looked like this:

Save recording:
   (gdb) record dump <filename>

Restore recording:
   (gdb) core <filename>
   (gdb) record


I would like to remark that the "restore" UI is logical but not
intuitive.  I think it would be helpful to have a single command eg:

   (gdb) record load <filename>

which would do the same as the "core" and "record" commands.

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?

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

[Tom Tromey]

>>>>> "Michael" == Michael Snyder <msnyder@vmware.com> writes:

Michael> I would like to remark that the "restore" UI is logical but not
Michael> intuitive.  I think it would be helpful to have a single command eg:
Michael>   (gdb) record load <filename>
Michael> which would do the same as the "core" and "record" commands.

Sounds good.

Michael> Secondly, I have a suggestion about the command names.
Michael> How about
Michael>   record save <filename>
Michael>   record restore <filename>
Michael> instead of
Michael>   record dump <filename>
Michael>   record load <filename>
Michael> What do you guys think?

This also seems reasonable to me.

Tom

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

[Eli Zaretskii]

> Date: Mon, 12 Oct 2009 09:11:04 -0700
> From: Michael Snyder <msnyder@vmware.com>
> 
> I would like to remark that the "restore" UI is logical but not
> intuitive.  I think it would be helpful to have a single command eg:
> 
>    (gdb) record load <filename>
> 
> which would do the same as the "core" and "record" commands.

I'm for it.

> 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>

I could go either way, but maybe you are right: "dump" and "load" are
two words with overloaded meanings.

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

[Joel Brobecker]

> How about
>   record save <filename>
>   record restore <filename>

Looks good to me.

-- 
Joel

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

[Hui Zhu]

>  record save <filename>
I think it is not bad.

>  record restore <filename>
I suggest we can make the core load and record together.  Because
record log is together with core.

Thanks,
Hui


On Tue, Oct 13, 2009 at 00:11, Michael Snyder <msnyder@vmware.com> wrote:
> OK, we set this discussion aside over a month ago, until after 7.0.
> Time to revive it?  Seemed like the implementation discussion had
> more or less stabilized, and we were mostly still discussing the
> user interface and docs -- so let's start there.
>
>
> In the last cycle, we had come down to a UI that looked like this:
>
> Save recording:
>  (gdb) record dump <filename>
>
> Restore recording:
>  (gdb) core <filename>
>  (gdb) record
>
>
> I would like to remark that the "restore" UI is logical but not
> intuitive.  I think it would be helpful to have a single command eg:
>
>  (gdb) record load <filename>
>
> which would do the same as the "core" and "record" commands.
>
> 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?
>
>

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

[Michael Snyder]

Hui Zhu wrote:
>>  record save <filename>
> I think it is not bad.
> 
>>  record restore <filename>
> I suggest we can make the core load and record together.  Because
> record log is together with core.

Yep!  I think we are all on the same page.

> On Tue, Oct 13, 2009 at 00:11, Michael Snyder <msnyder@vmware.com> wrote:
>> OK, we set this discussion aside over a month ago, until after 7.0.
>> Time to revive it?  Seemed like the implementation discussion had
>> more or less stabilized, and we were mostly still discussing the
>> user interface and docs -- so let's start there.
>>
>>
>> In the last cycle, we had come down to a UI that looked like this:
>>
>> Save recording:
>>  (gdb) record dump <filename>
>>
>> Restore recording:
>>  (gdb) core <filename>
>>  (gdb) record
>>
>>
>> I would like to remark that the "restore" UI is logical but not
>> intuitive.  I think it would be helpful to have a single command eg:
>>
>>  (gdb) record load <filename>
>>
>> which would do the same as the "core" and "record" commands.
>>
>> 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?
>>
>>

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

[Greg Law]

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?

Greg
-- 
Greg Law, Undo Software                       http://undo-software.com/

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

[Michael Snyder]

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.

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

[Greg Law]

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/

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

[Michael Snyder]

Greg Law wrote:
> 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.

Ah, I see.  Yeah, that might be a good idea.
In my mind, the deciding factor (whether it's
worth doing) would be, could we get like three
back-end maintainers to agree on what would be
a useful syntax / semantics for them.

Say, you, VirtuTech and VMware?

There are probably a lot of other backend-specific things
that we could agree to do if they were common enough, but
that might be best done with monitor commands if not.

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

[Hui Zhu]

Why this software cannot save the log with itself?

Hui


>
> Ah, I see.  Yeah, that might be a good idea.
> In my mind, the deciding factor (whether it's
> worth doing) would be, could we get like three
> back-end maintainers to agree on what would be
> a useful syntax / semantics for them.
>
> Say, you, VirtuTech and VMware?
>
> There are probably a lot of other backend-specific things
> that we could agree to do if they were common enough, but
> that might be best done with monitor commands if not.
>
>
>