This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]