Re: [RFA/RFC] Add dump and load command to process record and replay

[Michael Snyder <msnyder at vmware dot com>]

Eli Zaretskii wrote:
> > From: Hui Zhu <teawater@gmail.com>
> > Date: Tue, 4 Aug 2009 10:07:11 +0800
> > Cc: msnyder@vmware.com, gdb-patches@sourceware.org
> >
> > > By the way, does it make sense to make the dump file portable, so that
> > > another host that supports debugging the same target could then use
> > > it?
> > Yes, the dump file is portable like core file.
>
> Well, maybe I'm missing something important, but isn't the dump file a
> series of struct's defined as this:
>
>     struct record_entry
>     {
>       struct record_entry *prev;
>       struct record_entry *next;
>       enum record_type type;
>       union
>       {
> 	/* reg */
> 	struct record_reg_entry reg;
> 	/* mem */
> 	struct record_mem_entry mem;
>       } u;
>     };
>
> ?  If so, then the dump file uses host's native pointers, so it is not
> portable to a different host.  Right?

No.  If you look at the code that dumps the file (and I had
to add a bunch of printfs and stuff to figure it out), you'll
see that the dump file looks like this:

4 byte magic number
Series of the following:
1) 1 byte tag (record_end), or
2) 1 byte tag (record_rec) followed by
   8 byte number (register id), followed by
   MAX_REGISTER_SIZE byte value (register value): or
3) 1 byte tag (record_mem) followed by
   8 byte number (memory address) followed by
   8 byte number (memory length) followed by
   N byte buffer (memory value).

If you look for the #if (BYTE_ORDER == BIG_ENDIAN), this is
where Teawater is making the byte orders host-independent.

I was going to mention the ifdefs eventually.   ;-)